Good catch on the redundancy trap. Here is the cleaned post:

TLDR: Don't make Make.com reconstruct your data. Pre-build exactly what it needs in the payload — your server already has all the context.

The Setup

We built a consultation chat widget for a business that matches cancer patients to treatment facilities.

When a patient finishes a consult, the system fires a webhook to Make.com (our no-code automation platform), which routes the conversation to the right facility's inbox.

Simple enough on paper.

My Wrong Instinct

My first move was to enrich the payload.

Add more data. Give Make everything: the full messages array, the recipients list, the adminUrl. If Make has all the pieces, it can build what it needs.

That commit shipped: feat(webhook): enrich consult payload with recipients, messages, adminUrl.

And then I sat down to wire the Make scenario… and immediately saw the problem.

Every scenario had to loop the messages array, format each message, and concatenate them into something an email could actually use.

That's not Make doing what Make is good at.

That's Make doing work my server had already done.

The Fix That Worked

One new field.

chatTranscriptHtml

Pre-built, server-side, before the webhook fires. Complete HTML. The Make scenario just drops {{ chatTranscriptHtml }} into the email body and calls it done.

But here's the part I actually loved: we're routing to multiple facilities per consult. Each facility shouldn't see the others mentioned in the transcript. So we went further — each recipient gets their own pre-built HTML, with sibling facility names already redacted out.

feat(webhook): redact sibling-facility mentions from each recipient's transcript

Server-side. Before it leaves. Make never touches it.

Why This Pattern Matters

I've started calling this payload pre-building — and I keep seeing the same instinct apply in different contexts.

Your server has the full context at write time. The downstream consumer usually doesn't.

The receiver's job is to consume, not reconstruct. When you hand it raw material and expect it to fabricate the finished thing, you're fighting the tool instead of using it. (I've seen the same lesson come up building LLM pipelines — compute the expensive thing once, persist it, let every downstream stage just read. Same family of instinct.)

Make.com, Zapier, whatever automation layer you're running — these tools are GREAT at routing, triggering, branching. They're weak at data transformation. Every transformation step you push into Make is logic that's hard to test, hard to version, and annoying to rebuild if you ever swap the tool.

What I Do Now

Before I finalize any webhook payload, I ask one question:

Does the consumer need to transform this, or can I do it here?

If they'd have to transform it — I do it on my side first.

Pre-build the HTML. Pre-format the text. Pre-redact what shouldn't cross the wire. Your server has all the context. Use it.

P.S. This also protects you if the automation tool ever changes. Business logic lives in your payload builder, not scattered across Make scenarios you'd have to reconstruct from scratch.