Understanding Webhooks

A webhook is how one piece of software taps another on the shoulder the moment something happens. A customer pays, or a form gets submitted, or an order comes in. Instead of your software checking again and again to see whether anything has changed, the system that holds the information sends it to you the instant it appears.

Here is the analogy we use with clients. Most software integrations work like checking the peephole in your front door. You walk over, look out, see nobody, walk away, and repeat. A webhook is the doorbell. You get on with your day, and when someone arrives, you hear about it straight away. One approach burns your time on the off-chance; the other tells you the moment it matters.

That difference, push versus pull, is the whole idea. This article walks through the mechanics, the payload, the choice between webhooks and polling, and a ten-minute exercise where you watch one arrive.

An API waits; a webhook announces

An API (Application Programming Interface, the standard way one system asks another for data) works on a request-and-response model. As Amazon Web Services puts it, "the client sends requests to the server as data," and the server runs its functions and "returns output data back to the client." The key word is requests. With a plain API, your software has to ask. If you want to know whether a new order has come in, you call the API and check. Nothing arrived? Call again in a minute. This repeated asking is called polling.

A webhook flips the direction. GitHub's documentation describes webhooks as a way to "subscribe to events and automatically receive a delivery of data to your server whenever those events occur," and notes they are "used to receive data as it happens, as opposed to polling an API (calling an API intermittently) to see if data is available." GitHub also points out the practical payoff: webhooks "require less effort and fewer resources than polling" and give you near real-time updates. Their full guidance lives in the GitHub webhooks docs.

So the short version: an API is you asking a question. A webhook is the answer arriving on its own, the moment it becomes true.

What happens in the seconds after a customer pays

The mechanics are simpler than the name suggests. Twilio's documentation defines webhooks as "user-defined HTTP callbacks" that "are triggered by some event in a web application." In plain terms: you give a provider a web address you control, and when the event happens it sends the details there. The full sequence for a payment:

• 1.A customer pays $49 through your payment provider.
• 2.The provider records the event and builds a small parcel of data describing it.
• 3.It posts that parcel to the endpoint URL you registered in its settings.
• 4.Your endpoint checks the parcel's signature to confirm it genuinely came from the provider.
• 5.Your system acts: it marks the order paid, generates the invoice, and emails the receipt.
• 6.Your endpoint replies with a quick success acknowledgement, so the provider knows the delivery landed.

The parcel in step two is a small bundle of text in JSON, a format both machines agree on. A simplified version of what a payment provider sends looks like this:

{
  "event": "payment.succeeded",
  "created": "2026-07-05T09:14:03Z",
  "data": {
    "amount": 4900,
    "currency": "aud",
    "customer_email": "jo@example.com"
  }
}

One detail catches everyone the first time: the amount reads 4900 because payment systems count in cents rather than dollars, which avoids rounding errors. Your software divides by 100 before showing a human. A webhook, in other words, is a short, labelled message about one event. Nothing more.

Step four is the one you cannot skip

Your endpoint sits on the open internet, so in principle anyone who finds the address could send it a fake parcel. Stripe is blunt about the risk: "Without verification, an attacker could send fake webhook events to your endpoint to trigger actions." The standard defence is the signature check in step four, a tamper-proof seal your system verifies before acting; some setups also restrict which addresses may call the endpoint at all. This single check is the difference between a webhook that saves hours and one that becomes a liability.

Three webhooks that pay for themselves

Almost every useful automation we build for clients has a webhook at the start of it. Three come up constantly.

A payment is received, so an invoice goes out. When a customer pays, your payment provider fires a webhook. Stripe, for example, explains that once you register an endpoint, "Stripe can push real-time event data to your application's webhook endpoint when events happen," such as a payment succeeding. That single signal can generate the invoice, mark the order paid, and email the receipt, all without anyone opening a dashboard.

A form is submitted, so a CRM record and a team alert are created. A prospect fills in your contact form. The webhook fires, a new record lands in your CRM with their details already populated, and your team gets a message in their chat tool within seconds. No copy-pasting, no lead going cold while it sits in an inbox.

A new order arrives, so a shipping label is generated. An order comes through your store, the webhook triggers your fulfilment step, and a label is produced and queued for printing. The order moves from placed to ready-to-ship without anyone retyping the address.

None of these are exotic. They are the quiet plumbing behind a business that feels organised. We built a Lead Management System on exactly this pattern, and the chained automations behind it now save more than 1,500 hours of manual work a month and generate reports on their own.

The doorbell is not the doorman

Now the wrong belief we hear most often: the tool supports webhooks, so it will update my other systems. Owners see webhooks on a feature list and assume the automation comes with it.

It does not, for one simple reason. A webhook needs somewhere to land. The provider sends the parcel, but something you control has to receive it, verify it, and act on it. The webhook is the doorbell; your endpoint is the person who answers the door. Press a doorbell on an empty house and nothing happens.

In practice, that landing place is either software built for you or a no-code platform such as Zapier or Make, which provides a ready-made endpoint and lets you define what happens when a parcel arrives. Either way, someone has to decide which record gets created, which email goes out, and what happens when a field is missing. The correct model is that a webhook is the start of an automation, never the automation itself.

Webhook or polling: how to choose

Webhooks are not always available, so integrations sometimes fall back to polling. The trade-off is straightforward:

The verdict: use a webhook whenever the provider offers one and a delay costs you something, which covers payments, orders and leads. Poll on a schedule only when the system offers no webhooks, or when the data changes slowly enough that a snapshot once an hour is genuinely fine. In our experience most small-business automations are better served by webhooks: the events that matter most, money in and leads in, are the ones you want to know about straight away.

Watch one fire in the next ten minutes

You do not need a developer to see a webhook work, just a temporary landing place. A free tool called webhook.site provides one.

• 1.Open webhook.site in your browser. It generates a unique, disposable endpoint URL the moment the page loads. Copy it.
• 2.In a tool you already use (most form builders, e-commerce platforms and payment providers support webhooks), find the setting, usually under Settings, then Webhooks or Integrations.
• 3.Paste the disposable URL as the endpoint and choose an event to subscribe to, such as form submitted.
• 4.Trigger the event yourself: submit a test entry through your own form.
• 5.Switch back to webhook.site. Within a few seconds a request appears, and you can read the JSON parcel with your test data inside it.
• 6.Delete the webhook from your tool when you are done. A disposable URL is for the demonstration, not for live business data.

That is the entire mechanism, seen end to end: an event on one side, a parcel arriving at a URL on the other.

How we wire them at Enki

We treat a webhook as the starting gun of an automation, never the finished product. Setting one up takes three steps: create the endpoint, register it with the provider and choose the events, then test it with a sample delivery. The work that earns trust comes after the doorbell rings: verifying signatures, handling the parcel, and testing the whole chain before it touches real money or real leads. If you have ever watched a paid order turn itself into an invoice, a shipped parcel and a tidy CRM entry without anyone touching it, you have watched this one small idea doing the heavy lifting.