What is a webhook?
What is a Webhook?
A webhook is an automated HTTP callback that one application sends to another when a specific event occurs. Instead of a client repeatedly asking a server for updates, the server pushes a notification, usually an HTTP POST request with a JSON payload, to a URL the client has registered. Webhooks are how modern APIs and web services deliver real-time data to other applications.
Another way to think about webhooks is that they are push notifications between apps. The server detects that an event has occurred, which triggers it to send a message to the client app.
How do webhooks work?
A webhook exchange has three parts:
- The receiver registers a webhook URL. This is a webhook endpoint on the receiving application, sometimes called a callback URL, that is ready to accept incoming HTTP requests.
- An event occurs on the sender's side. A payment succeeds, a user signs up, a file finishes processing. Each kind of notification is usually identified by an event type.
- The sender makes an HTTP POST request to the registered URL. The request body is the webhook payload, typically JSON describing the event. The receiver acknowledges it with a
2xxresponse.
If the receiver is down or responds with an error, well-designed webhook senders retry the delivery, usually with exponential backoff, until it succeeds or a retry limit is reached.
Webhooks vs. APIs
Webhooks and APIs both enable communication between apps, but with an API the communication is initiated by a request from one app (the client) to another (the server).
The server then sends a response back to the client.
Webhook communications do not involve a client-side request. The server simply sends a request when predetermined conditions are met. The two are complements, not competitors: most integrations use both, an API for reading and writing data, and webhooks for finding out when that data changes.
Webhooks vs. polling
Webhooks are a great solution when the client does not know when an event will occur and wants to be notified in real time. To accomplish this with an API alone, you would need to implement API polling: sending continuous API requests to check for updates. Polling wastes bandwidth and computing resources for both the client and the server, since the vast majority of requests come back empty. Webhooks are a much more efficient solution to the problem of real-time event notification.
For a deeper comparison, see webhooks vs. API polling.
Webhook examples
Almost every major platform uses webhooks to notify integrations about events:
- Stripe sends a webhook when a payment succeeds or fails, so your app can fulfill the order.
- GitHub sends a webhook when code is pushed, triggering CI builds and deployments.
- Slack receives webhooks from other apps to post messages into channels.
- Shopify sends webhooks when orders are created or updated, keeping inventory systems in sync.
In each case the pattern is the same: an event happens in one system, and other systems find out about it immediately, without polling. This push-based model is why webhooks power most workflow automation between apps, and it makes webhooks the simplest way to adopt event-driven architecture without running your own event broker.
How to receive webhooks
Receiving webhooks starts with three steps: expose an HTTPS endpoint that accepts POST requests, register that URL with the sending service, and return a 2xx response when deliveries arrive. From there, a production-ready receiver needs a bit more care: verify the signature on every request before trusting it, respond quickly and do the real work asynchronously so the sender does not time out and retry, and handle duplicate deliveries, since retries mean the same event can arrive more than once. Our first webhook endpoint tutorial walks through building one, and the receiving best practices guide covers the details.
If you would rather not build and operate that infrastructure, Svix Ingest is a managed gateway for receiving webhooks. It verifies signatures from popular providers like Stripe, GitHub, and Shopify out of the box, absorbs traffic spikes with configurable throttling, retries failed deliveries into your systems, and can filter, transform, and fan out events to multiple destinations. It can even expose incoming webhooks over a polling endpoint for receivers behind a firewall.
Are webhooks secure?
Because a webhook endpoint is a publicly reachable URL, receivers need a way to verify that incoming requests genuinely come from the expected sender. The standard approach is webhook authentication using webhook signatures: the sender signs each payload with an HMAC secret, and the receiver verifies the signature before trusting the request. Senders should also deliver webhooks exclusively over HTTPS.
For a practical checklist, see our webhook security best practices.
When not to use webhooks
Webhooks are not the right tool for every job, and knowing the limitations helps you design around them. Delivery is not guaranteed by default: if the receiver is down and the sender does not retry, the event is simply lost, which is why serious webhook systems pair retries with a dead letter queue. Ordering is not guaranteed either, since retries and parallel delivery mean events can arrive out of sequence, so receivers should rely on timestamps or event IDs rather than arrival order. And because webhooks require a publicly reachable URL, they are awkward for local development and for receivers behind firewalls; see our webhook testing guide for ways to work around this.
Finally, webhooks are for event notifications, not for everything. If a browser needs a continuous two-way stream, use a WebSocket. If you need to fetch or backfill large amounts of data, use the API directly. Webhooks work best telling you that something happened, so your systems can decide what to do about it.
Learn more about webhooks
Now that you know what a webhook is, Webhooks University covers webhook fundamentals, implementation, reliability, and security in depth, and the glossary defines the rest of the webhook terminology you will run into.
Why Svix?
Svix is an open source Webhooks as a Service product that simplifies the process of building a reliable, secure, scalable webhook solution.
When building your own webhooks you have to deal with a lot of challenges: unreliable user endpoints, monitoring and reliability of your webhook system, security implications unique to webhooks, and much more.
This is where we come in. With Svix you can start sending webhooks in under five minutes, and we take care of all of the above and more.
Svix offers a REST API and a set of libraries for interacting with our service.
In addition to helping you send webhooks to your users, we also help your users easily verify the authenticity and security of the webhooks they receive from you.
We offer easy to use docs for how to safely consume webhooks which you can share with your users directly: Consuming Webhooks documentation.
As part of that we offer a set of open-source libraries that your users can use when consuming webhooks.
If you have any questions, or you just want to chat, please join the Svix Slack community.