Module · Webhooks
What is a webhook
Lesson 1 of 11 · 4 min
People get stuck on webhooks, and it is almost never the interface. It is that nobody explained what one is. The word suggests something is being hooked to something, which is not what happens, and the explanations tend to start with HTTP verbs rather than with the problem.
So: three minutes on the idea, then three lessons of building. There is nothing to configure on this page.
Two ways for systems to stay in sync
Suppose your CRM needs to know when a payment succeeds in another system. There are exactly two ways it can find out.
| Polling | Webhooks |
|---|---|
- Webhooks
- Webhooks
- Webhooks
- Webhooks
That is the entire pitch. When a payment clears, a meeting is booked, a form is submitted — those systems do not wait to be asked. They push the news out the instant it happens, and anything that wants to know has agreed in advance where to be told.
A webhook is an HTTP POST
Underneath the word, a webhook is one system making an ordinary web request to another. Three parts, and no fourth:
- A URL. An address the receiving system published, saying: send it here.
- A payload. Some JSON describing what happened — which payment, which customer, how much.
- A secret. Something proving the message really came from who it claims. Without it, anyone who learns the URL can send you whatever they like.
POST https://your-system.example/hooks/payments
Content-Type: application/json
{
"event": "payment.succeeded",
"amount": 4900,
"currency": "INR",
"customer_email": "someone@example.com"
}If that looks like the API Request node from the previous path, it is — the same request, seen from the other end. That symmetry is the whole of the fourth lesson in this module.
Which end are you?
This is the distinction to hold on to, because the two directions use different parts of the product and people mix them up constantly.
| Direction | What it means | What you build |
|---|---|---|
| Incoming | ||
| Outgoing |
Incoming
- What it means
- What you build
Outgoing
- What it means
- What you build
A useful test: who is doing the calling? If the other system is calling you, that is incoming and you need a URL to give them. If you are calling them, that is outgoing and you need theirs.
What goes wrong, conceptually
A webhook is fire-and-forget from the sender's point of view. The system sending it usually does not care what happened next. If your workflow errors, the sender's job is done and the event is gone. This is why the debugging lessons in this module matter more for webhooks than for anything else in the course: a failed webhook is often a thing that simply never happened, with nobody to notice.
Delivery is not guaranteed and is not always once. Networks fail, so most senders retry — which means the same event can arrive twice. A workflow that creates a record on every webhook will occasionally create two. Where that matters, key the work on something in the payload rather than on the fact that a message arrived.
The URL is a door. Anything that can reach it can trigger your workflow. The secret is what turns “anyone who found this address” into “the system I agreed to listen to”, and it is the field people skip because everything works without it.
Before you go on
- Pick a system you already use — a payment provider, a form tool, a scheduler — and find its webhooks page. Read what events it offers to send.
- Decide, for something you actually want to automate, which direction it is. Who calls whom?
- Look at the sample payload the other system publishes. That JSON is what your workflow will be reading in two lessons' time.
Next: Incoming webhooks — creating the URL, giving it out, and starting a workflow the moment somebody uses it.