Most developers can say "a webhook is when something notifies you automatically." Fewer can explain exactly what's different about it compared to a regular API call, or why it's the piece that makes so much real-time automation work.
Here's the actual mechanics, without skipping the part that usually gets glossed over.
The core difference: who starts the conversation
A regular API call is you asking a question. You send a request, the other system responds, and you're the one who decided when that happened. If you want to know whether a payment went through, you'd have to ask — repeatedly, on some kind of schedule — until you got an answer.
A webhook flips that. Instead of you asking, the other system tells you the moment something happens. You give it a URL ahead of time, and when the event occurs, it sends a request to that URL on its own. No polling, no asking over and over. A fuller breakdown of what a webhook actually is goes through the request format and setup in more detail if you want to see it end to end.
A concrete example
Say you're taking payments through Stripe. Without a webhook, you'd have to keep checking "did this payment go through yet?" on some interval, which is slow and wastes requests. With a webhook, you register a URL, and the moment the payment completes, Stripe sends a POST request to that URL with the payment details. Your server receives it and updates the order immediately — no polling loop involved.
That's the whole value: your system reacts the instant something happens, instead of finding out about it late.
Where it fits with APIs in general
Webhooks aren't a replacement for APIs — they're a different direction of the same idea. A regular API is request-then-response, initiated by you. A webhook is event-then-request, initiated by the other system. If the underlying concept of a request and response is still fuzzy, this plain explanation of what an API is is worth reading first, since webhooks build directly on top of it.
The part people half-understand
The most common gap isn't the concept — it's what happens after the webhook arrives. A webhook is just an HTTP request landing on your server. Your code still has to verify it's actually from who it claims to be (usually with a signature check), handle it quickly so the sender doesn't time out and retry, and deal with the fact that most services will retry the same event if they don't get a fast response — meaning your endpoint needs to handle receiving the same event twice without doing the action twice.
That last part trips up a lot of people building their first webhook handler. If your endpoint isn't idempotent — meaning running it twice with the same input has the same effect as running it once — a retried webhook can double-charge a customer or send a duplicate notification.
Where webhooks show up in automation
Anything reacting to an event in real time is probably built on a webhook somewhere underneath. A GitHub Action that runs on every push, a Slack bot that responds when someone reacts to a message, a monitoring tool that pings you the moment a site goes down — all of these are triggered by a webhook rather than a schedule.
If you're building an automated workflow and it feels like it should react instantly rather than run on a timer, that's usually the sign you need a webhook instead of a scheduled check.
More practical breakdowns like this one over at Procwire.
Top comments (0)