What is a webhook?
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.
Frequently asked questions
How is a webhook different from an API?
Webhooks are push-based and APIs are pull-based: with a webhook the sending service invokes your endpoint when an event happens, while with an API your code calls the source and asks. The difference shows up in latency, in cost, and in which side owns the failure handling.
What does a webhook receiver have to send back?
A 2xx response, which acknowledges receipt rather than completion. The reliable pattern is to acknowledge quickly and process asynchronously, because most providers treat a slow response as a failure and retry it.
What do production webhook systems need beyond the HTTP request?
Signature verification, idempotency, retries with backoff, dead-letter handling, replay, and delivery observability. The protocol is simple; the operating burden is not, and each of those is a separate thing to build and run.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
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 - Workflow blueprint
A dashboard-curated starting template for a first-workflow path.
Read