What is a webhook?
A webhook is a URL you give another system so it can call you the moment something happens there, with the details in the request. You get told instead of having to keep asking, which is why every automation that has to react within seconds is built on one.
TL;DR verdict
If a vendor tells you a sync runs "every 15 minutes", they are polling. On a lead form, that hands a 15-minute head start 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 |
| Behavior if your side is down | Lost unless the sender retries, and some never do | Catches up on the next poll |
| Good for | Reacting fast to events | Bulk sync, systems with no webhooks |
Which we'd pick, scenario by scenario
A lead form on your site
The form posts to a webhook, the automation enriches and routes the lead, and the first contact goes out before the person has closed the tab. That 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 update at once. With polling, the accounting 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 the right call
The other system offers no webhooks, or you need a nightly reconciliation that catches anything missed. We usually run both: webhooks for speed and a scheduled sweep for completeness.
Webhooks are the least exciting part of an automation and the one that most often decides whether a project hits its number, because 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 outcomes often comes down to an event push versus 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. Some providers retry for a while and then drop the event, and others never retry at all, 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 process automation we ship.
Sources
Frequently asked
What is a webhook in simple terms?
A phone number you give another system so it can ring you when something happens, instead of you ringing it every few minutes to ask. The call carries the details of what happened.
What is the difference between a webhook and an API?
Direction. With an API, you call the other system when you want something. With a webhook, the other system calls you when it has something. Most integrations use both: a webhook to hear about the event, then API calls to act on it.
Are webhooks secure?
As secure as you make them. The endpoint is public, so it needs HTTPS, signature verification against a shared secret and rejection of anything that fails the check. An unverified webhook endpoint is an open door, and we treat it as a build blocker.
What happens if my system is down when a webhook fires?
Some senders retry for a while and then give up, and some, GitHub among them, never redeliver automatically, so the event can be lost for good. For anything that matters we add a scheduled reconciliation that compares both systems and fills in whatever the retries missed.
Do I need a webhook for a WhatsApp bot?
Yes. Meta delivers inbound WhatsApp messages by calling a webhook URL you register and verify. There is no polling option, so a public HTTPS endpoint is the first thing we set up on any WhatsApp project.
Which process costs you the most?
Thirty minutes, free. You leave with a concrete fix plan and what the process costs you. The plan is yours, even if you build it without us.
Book a free audit