Webhooks explained for people who do not write code

Somewhere in most people's no-code stack is a step that checks a spreadsheet every five minutes to see if anything new showed up. It works. It also means that on average, the automation finds out about a new row two and a half minutes after it arrived, burns a task or an operation on every single check whether anything changed or not, and if you're on a plan with a task cap, spends most of that budget confirming that nothing happened. We have watched people burn through a Zapier plan's monthly task allowance almost entirely on polling, then wonder why the automation that actually matters keeps running out of runway by the twentieth of the month.

A webhook is the fix, and it is a smaller idea than the explanations make it sound. Think of a doorbell rather than a mail carrier doing rounds. You don't send someone to check your front door every five minutes; the door notifies you the moment someone is there. A webhook is that notification, sent automatically from one service to another the instant something happens — a form submission, a payment, a new row, a status change — with no polling involved on either side.

Where the notification actually comes from

The service with the news — Stripe, Typeform, Airtable, a payment processor, a CRM — sends an HTTP request to a URL you gave it, the moment the event happens. That URL belongs to your automation platform: Zapier's "Catch Hook" trigger, Make's webhook module, n8n's Webhook node. The request carries a payload, which is just the details of what happened, and your automation wakes up, reads the payload, and does whatever comes next.

Not everything can send you one. A webhook requires the sending service to have built the feature, and it requires there to be a form or event on their side to hook into in the first place. This is worth naming because it is where reach falls outside the whole topic of this article: a reach-generated personal site has no contact form that posts anywhere, only a mail link and profile links in the contact section, so there is nothing on a reach page that could ever trigger a webhook. If your plan for a personal site involves catching form submissions in an automation, that is a job for a tool built around forms — we cover the field properly in our comparison of no-code form tools — not for a one-page CV site. Different job, and reach isn't trying to do this one.

Polling versus a webhook, in practical terms

Polling asks "did anything happen?" on a timer, whether or not the answer is yes. A webhook tells you the moment the answer is yes and stays silent otherwise. Two consequences follow directly from that.

The first is latency. A poll every five minutes means a worst-case delay of five minutes between the event and your automation noticing it, and an average delay of half that. A webhook's delay is however long the HTTP request takes to arrive — typically under a second.

The second is cost, and on most no-code platforms cost is measured in tasks or operations, not time. A polling trigger spends a task on every check, including the overwhelming majority that find nothing new. A webhook spends nothing until there is genuinely something to process. For a workflow that checks a quiet source every few minutes, this is often the difference between a workflow that comfortably fits inside a free tier and one that does not.

Reading a payload without knowing JSON

A payload looks intimidating the first time you see the raw text, and it is not. It is labelled boxes, some sitting inside other boxes. A key is the label; a value is what's in the box. "email": "person@example.com" is a key called email holding a value. Curly braces group related keys together — a customer box might contain name, email and id inside it — and that's nesting: a box inside a box, reached by opening the outer one first.

You will rarely need to read raw JSON in a no-code tool. Zapier, Make and n8n all let you send one real test event, then show you the payload as a list of fields you can click, already flattened out of the nesting for you. The one habit worth building regardless: send that test event before you build anything downstream, so you are mapping real field names rather than guessing at what the documentation says they might be called.

Setting one up end to end

The shape is close to identical across platforms. Create the trigger step and choose "webhook" as the source; the platform generates a unique URL — copy it. Paste that URL into the sending service's webhook or integration settings, wherever it asks where to notify. Trigger one real event on the sending side — submit the form, create the test record, process a test payment. The automation platform catches that first request and uses it to show you the payload, field by field, which you then map into whatever comes next: a row in a spreadsheet, a message in Slack, a record in a CRM.

Do this with a genuinely disposable test event, not your first real customer's data. Most platforms hold onto the sample payload as a template for the rest of the field mapping, and finding a stray test order in your production spreadsheet later is a small but avoidable annoyance.

The two failures that account for almost everything that breaks

We have debugged a lot of these, and it is nearly always one of two things.

The first is your side returning anything other than a 200 status. Webhooks are built around a simple contract: the sender delivers, your receiver returns a success code, and the transaction is considered closed. If your automation platform is slow, times out, or returns an error partway through — a downstream step fails, an API you're calling is rate-limited — the sender never sees that 200, and it does not know the event was actually received. This is the single most common cause of a webhook integration that "sometimes just stops working," and it is worth reading automation error handling basics before you wire anything past a demo, because the fix is almost always in how failures downstream are surfaced, not in the webhook step itself.

The second is the mirror image: the sender retrying because it assumed delivery failed, and your automation processing the same event more than once. Most webhook senders retry on anything other than a clean 200 — reasonably, since from their side a timeout looks identical to a request that never arrived — and if your automation isn't built to notice it has already seen this event, you get a duplicate row, a duplicate Slack message, a duplicate charge. The fix is to check for a unique identifier from the payload — an order ID, a submission ID — before creating anything, and skip the step if that ID already exists downstream. It's a few extra minutes to build and it is the difference between a webhook you can trust unattended and one you have to keep checking, which is the whole argument we make in automation that survives a month: the automations that last are the ones built assuming something will eventually go wrong, not the ones built assuming it won't.

Look at the traffic before you trust it

Before wiring a webhook into anything that matters, point it at a request-bin style tool — webhook.site is the one we reach for — instead of your real automation. These sites hand you a disposable URL and show you every request that arrives at it: headers, body, timing, retries, all of it, with no automation logic in the way to obscure what actually got sent. It answers the two questions that matter before you build anything downstream: does the payload actually contain the fields you expected, and does the sender retry, and if so how often. Ten minutes here saves the debugging session where you can't tell whether the problem is what was sent or how your automation interpreted it.

The security basics that actually matter

A webhook URL is not a password, and it is worth being clear-eyed about what that means. Anyone who obtains it — pasted into a shared doc, visible in a screen share, logged somewhere it shouldn't be — can send a request to it and your automation has no built-in way to tell that request apart from a genuine one. The URL being hard to guess is obscurity, not security.

For anything beyond a toy, the real protection is a signing secret. Services that take webhooks seriously — Stripe is the clearest example — send a signature alongside the payload, computed from the payload contents and a secret key only you and the sender know. Your automation recomputes that signature on its end and checks it matches before doing anything with the data. If it doesn't match, the request didn't genuinely come from the service it claims to. Most no-code platforms support this as a step you add, not something built in automatically, so it is worth checking for a signature-verification action or built-in step before assuming the platform is protecting you already. If the source you're integrating with doesn't offer signing at all, the honest fallback is to keep whatever the webhook triggers reversible — write to a staging sheet you review rather than firing an irreversible action straight off an unverified request.