What is a webhook? How they work and when to use them | Svix Resources

A webhook is an automated HTTP request that one system sends to another the moment an event occurs. Instead of your application repeatedly asking a service whether anything has changed, the service pushes a notification to a URL you provide as soon as something happens: a payment succeeds, a user signs up, a file finishes uploading.
To see why that matters, consider the alternative. You have two systems that need to talk to each other, and System A has data that System B cares about. With polling, System B asks System A “anything new?” every few seconds. This works, but it is wasteful. Most of the time, the answer is “no, nothing new,” and you have burned an API call for nothing. If you poll too frequently, you waste resources. If you poll too infrequently, you miss time-sensitive updates.
Webhooks flip this model around. Instead of System B constantly asking System A for updates, System A pushes updates to System B the moment something happens. System B provides a URL (the webhook endpoint), and System A sends an HTTP POST request to that URL whenever there is new data.
The purpose of a webhook is to let one system notify another the moment something happens, without the second system having to ask. That removes polling: instead of calling an API every few seconds to check for changes, the receiver gets one HTTP POST per event, typically within seconds of it occurring. Payment confirmations, new orders, code pushes, and support tickets are the usual triggers, and webhook examples shows the exact requests Stripe, GitHub, and Shopify send for them.
With a traditional API, communication starts with the client: your application sends a request to another system and waits for a response. Webhooks reverse that direction. The server sends the request, pushing data to you as soon as an event occurs, with nothing on your side needed to trigger it.
The two are complements, not competitors. Most integrations use both: an API for reading and writing data on demand, and webhooks for finding out when that data changes. For a side-by-side comparison, including where webhooks fall short, see webhook vs API.
When you integrate with a service that supports webhooks, you typically register an endpoint URL with that service. This is your callback URL, sometimes called the webhook URL, the place where you want to receive notifications. When an event occurs (a payment succeeds, a user signs up, a file is uploaded), the service constructs an HTTP request containing information about that event and sends it to your endpoint.
Your server receives this request like any other incoming HTTP request. You parse the payload, validate that it actually came from the expected sender, and then do whatever your application needs to do with that information. Finally, you return a 200 OK response to acknowledge receipt.
The service on the other end typically expects a quick response. If your endpoint takes too long to respond, or returns an error status code, the sender treats the delivery as failed. What happens next depends on the sender, which is what the next section is about.
A webhook works in five steps. You register an HTTPS URL with the sender. When an event occurs, the sender POSTs a JSON payload to that URL with an event ID, a timestamp, and an HMAC signature in the headers. Your server verifies the signature and returns a 2xx status within the sender’s timeout. If it returns a 5xx or times out, the sender retries with exponential backoff.
A webhook request is just an HTTP POST with a JSON body, though some services use other formats. The request usually includes several important pieces of information.
The payload contains the actual event data. This might be the full details of the object that changed, or it might be a minimal notification that something happened (requiring you to fetch details separately). The choice between “fat” and “thin” payloads is a design decision with tradeoffs we will cover in a later article.
Headers often carry metadata like the event type, a signature for verification, and a timestamp. Providers following the Standard Webhooks spec standardize these as the webhook-id, webhook-timestamp, and webhook-signature headers. The signature is critical for security since it lets you confirm the request actually came from the expected sender and was not spoofed by an attacker.
An event ID or delivery ID identifies the event independently of any single delivery attempt, which matters because the same event can be delivered more than once, as covered below.
On the sender’s side, delivery is almost never part of the original transaction. When the event occurs, the application writes it to a queue and moves on; a separate worker picks it up, builds the signed HTTP request, and handles delivery. This decoupling matters because delivery can be slow or fail outright, and neither should block the application that generated the event.
The request then makes an ordinary network journey: DNS resolution to find your server, a TCP connection, and a TLS handshake before the POST is sent. Each step can fail in its own way: DNS errors after you change an endpoint URL, connection failures when your server is down or unreachable, TLS failures when a certificate expires. The sender wraps the whole attempt in a timeout, typically between 5 and 30 seconds, and treats anything slower as a failure.
Your response status code tells the sender what to do next. A 2xx means delivery succeeded. A 4xx means something is wrong with the request itself, an invalid signature or a malformed payload, and most senders will not retry it because retrying will not fix it. A 5xx or a timeout means a temporary failure on your side, which is what triggers the retry machinery described next.
Webhook delivery is best-effort unless the sender says otherwise. A well-designed provider retries failed deliveries with exponential backoff: a typical schedule attempts delivery after 5 minutes, then 30 minutes, then a few hours, spreading attemp