What is a webhook?
A webhook is a URL you give to another system so it can call you the instant something happens there, sending the details in the request. It is the difference between being told and having to keep asking, which is why every automation that has to react in seconds is built on one.
Reviewed:
In short
If a vendor tells you a sync runs "every 15 minutes", they are polling. For a lead form that is a 15-minute head start handed to whoever answers first. Ask whether they support webhooks before you ask about anything else.
| Webhook | Polling | |
|---|---|---|
| Who starts the call | The system where the event happened | Yours, on a timer |
| Typical delay | Under a second | Half the polling interval, on average |
| Cost when nothing happens | Nothing | Every empty check still runs |
| Needs a public URL | Yes | No |
| Behaviour if your side is down | Retries, then the event is lost | Catches up on the next poll |
| Good for | Reacting fast to events | Bulk sync, systems with no webhooks |
Sources: GitHub docs: about webhooks · n8n docs: webhook node · reviewed: Jun 17, 2026
Where it shows up in practice
A lead form on your site
The form posts to a webhook, the automation enriches and routes it, and the first contact goes out before the person has closed the tab. This is the whole mechanism behind cutting response time to seconds.
A payment that clears
The payment provider calls your webhook, and the invoice, the CRM stage and the delivery note all move at once. Polling here means an accounting system that is right on average and wrong at any given moment.
An inbound WhatsApp message
Meta delivers each message to a webhook you register. There is no other way to receive them, which is why every WhatsApp build starts with a public HTTPS endpoint and a verify token.
When polling is still correct
The other system offers no webhooks, or you need a nightly reconciliation that catches anything missed. We usually run both: webhooks for speed, a scheduled sweep for completeness.
How we use it
Webhooks are the least interesting thing on this list and the one that most often decides whether a project hits its number. The reason is that reaction time is usually the whole value. A lead answered in thirty seconds and the same lead answered forty minutes later are not the same lead, and the gap between those two outcomes is often just the difference between an event push and a five-minute timer.
Two practical notes from running these in production. First, treat the endpoint as public and hostile: verify the signature the sender provides, and reject anything unsigned, because a webhook URL is a door into your automation. Second, plan for the sender giving up. Most providers retry a handful of times and then drop the event, so anything that must not be lost gets a nightly sweep that compares both sides and fills the gaps. We used exactly this pairing on the build described in cutting first contact from 4.5 hours to 30 seconds, and it is standard in every business automation we ship.