What is a webhook?
It is the difference between hearing about a refund in under a second and finding out on the next scheduled check.
Webhook
HTTP callback
A webhook is an HTTP request that one system sends to a URL you host, fired automatically the moment a specific event happens. Instead of your system asking "did anything change?" on a schedule, the event arrives on its own.
You register a URL with the sending system: a payment provider, a form tool, a CRM. When the event you subscribed to happens, that system sends a POST request to your URL with the event details in the body.
Your server has to be listening for it. There is no reply beyond a status code telling the sender the delivery worked.
Why webhooks replace polling
Polling means your system calls an API on a timer, asking for anything new. Check every five minutes and an event can sit unhandled that long. Ask every second instead, and you burn through rate limits for mostly empty answers.
A webhook flips who does the work. The sender pushes the event the moment it happens, so your system reacts in near real time without asking. That is the whole trade: less wasted traffic, but you now run a public endpoint that anyone can attempt to call.
Running that endpoint safely comes down to three rules. Verify who actually sent the request. Respond fast and do the real work afterward. Design for the same event arriving more than once.
- Event firesSomething happens at the sender.
- POST arrivesYour URL receives the payload.
- VerifyCheck the signature before trusting it.
- AcknowledgeReturn 200 in under a few seconds.
- ProcessReal work runs after, off the request.
Skip the acknowledge step and do the work inline, and a slow database call turns into a timeout the sender reads as failure.
Common questions
01What is the difference between a webhook and an API?
An API is something you call when you want data or want to trigger an action; you decide when to ask. A webhook is the reverse: the other system calls you, on its own schedule, when its event happens. Most integrations use both, an API to set things up and a webhook to hear back.
02Webhook vs polling: which one should you use?
Use a webhook when the sender offers one and near real-time matters. It avoids both the delay and the wasted calls that polling costs. Fall back to polling when no webhook exists or you cannot expose a public endpoint. Polling also earns its keep as a reconciliation pass, catching anything a missed delivery would otherwise lose silently.
03Why did my webhook fire twice for the same event?
Most providers guarantee at-least-once delivery, not exactly-once. If your server is slow to respond, or a network blip loses the acknowledgment, the sender retries and you get the same event again. The fix is deduplicating on the event's ID, not trying to make the sender send it only once.
04How do you secure a webhook endpoint?
Verify the signature the provider sends with every request before you trust the payload, using the shared secret from your account with that provider. Reject anything that fails the check, and use HTTPS so the payload cannot be read or altered in transit.
