A webhook flips the question. Instead of asking every five minutes whether anything is new, you leave an address and the service writes to you the moment it happens.
It is the mechanism behind most real-time automations, and also the most misunderstood piece of the machinery: many people file it under technical when it is first of all a decision about architecture and cost.
Definition
A webhook is a notification sent automatically by a service to an address you supplied, at the precise moment an event occurs.
Technically it is an inverted API call. Normally you call the service. Here the service calls you. Hence the name sometimes used, HTTP callback.
The parcel comparison lands best. Polling is checking your letterbox every ten minutes. A webhook is the notification telling you the postman has been. Same result, but one ties you up permanently and the other does not.
What it changes in practice
| Polling | Webhook | |
|---|---|---|
| Calls per month | Thousands | One per real event |
| Reaction time | Up to the chosen interval | Immediate |
| Setup | A few clicks | One address to declare |
| If your tool is down | Caught up next pass | Lost, unless the sender replays |
That last line is the only real drawback, and it can be handled. Serious services retry several times after a failure, often for hours. Check that behaviour in their documentation before building on it.
Three points to watch
The address is an open door
Your receiving address accepts messages from outside. If it circulates, anyone can send you fake events. Most services offer a signature to verify: that is the first setting to configure, not an option.
The same event can arrive twice
That is the direct consequence of replay. If your processing creates an invoice, receiving the same event twice creates two. Your Workflow must recognise an already-handled event and ignore it.
You have to answer fast
The sender expects a response within seconds, otherwise it treats the delivery as failed. If your processing is long, answer immediately and work afterwards, rather than keeping it waiting.
Never put sensitive information in the address itself. It shows up in the logs of many systems. Shared secrets and signatures belong in the message headers, never in the URL.
Testing a webhook before building on it
The method that saves the most time is looking at what actually arrives before writing a single step. The data received almost never resembles what you imagine from reading the documentation.
Declare the address and do nothing else. Your automation tool provides a test address that displays incoming messages as they are.
Trigger the event for real. Place a test order, fill in the form yourself. The "send a sample event" functions some services offer send idealised data that does not have the shape of the real thing.
Read what arrives. Note the fields actually present, those that are empty, those named differently from what you expected. You build from that structure, not from the documentation.
Trigger the edge case. An order with no address, a customer with no name, a zero amount. That is where you discover the missing fields that will break your Workflow in three weeks.
Check the replay. Switch your tool off, trigger the event, switch it back on. If the message arrives late, the service replays and you are protected. If it never comes, you will need a periodic catch-up.
Frequently asked questions
Do you need a server to receive one?
No. Automation tools give you a ready-made address. You paste it into the sending service, and the Trigger is in place within two minutes.
How do you test before going live?
Most tools display incoming messages live. Fire the event once for real, look at what arrives, and build the rest from the data actually received rather than the data you imagine.
How is it different from MCP?
A webhook announces an event. MCP lets a model use tools. The first is an incoming signal, the second a means of acting. They complement each other more than they resemble each other.
How do you set up your first one?
By starting from a service you already use that offers them, a payment or form tool for instance. Our n8n course shows that connection from start to finish, security signature included.