A webhook is an HTTP request one service sends to another to notify it that something happened. The sending service POSTs a JSON body to a URL the receiving service has registered. The receiving service responds with 2xx to acknowledge.
That's the entire pattern. Webhooks are push-based (the sender invokes the receiver) where APIs are pull-based (the caller invokes the source). The difference matters for latency, cost, and how failure modes work.
Common examples
- Stripe POSTs a webhook when a payment succeeds or fails
- GitHub POSTs a webhook when a PR is merged or a release is published
- Slack POSTs a webhook (Events API) when a user mentions your app
- Shopify POSTs a webhook when an order is created or refunded
Every modern SaaS platform exposes webhooks for the events its consumers care about.
What makes webhooks hard at scale
The protocol is simple. The operating burden is not. Production webhook systems need:
- Signature verification so forged events don't reach your handler — see HMAC
- Idempotency so retries and duplicates don't produce conflicting state — see idempotency
- Retries with backoff so transient failures don't lose events — see retry
- Dead-letter handling so terminal failures are recoverable — see DLQ
- Replay so failures can be re-run after a fix — see replay
- Observability so you can answer "did the event arrive?" without grepping logs — see observability
For deeper reading: What is a webhook? covers the full primer; Webhooks vs APIs covers when to use each.
Related terms
- Payload
The body of an HTTP request — for webhooks, almost always JSON.
Read - Idempotency
A property where performing an operation multiple times produces the same result as performing it once.
Read - HMAC
Hash-based Message Authentication Code — proves a message came from someone who knows a shared secret and was not modified.
Read - Replay
Re-running a retained event with the same input — typically after fixing a bug that caused the original to fail.
Read