What Is a Webhook?
How Webhooks Deliver Events
What is a webhook? A webhook is an HTTP callback: when something happens in one system, that system sends an HTTP POST request containing the event details to a URL you have registered. It is the same kind of message as any API call, but the sender starts it, not your application.
A typical example is a payment. When a customer's payment succeeds, the payment provider sends a webhook to the shop's server, which can then mark the order as paid, send a receipt or update stock. The request body usually contains an event type and a JSON payload with the relevant data, such as an order ID and an amount. Webhooks are a common building block of API integrations between separate services.
Webhooks vs Polling
The alternative to a webhook is polling. With polling, your application calls the API on a schedule, such as every minute, and asks whether anything new has happened. Polling is simple and works with any API that offers read endpoints, but updates can arrive late, and most polling requests find nothing new, which wastes time and request quota.
Webhooks reverse the direction. They deliver changes as soon as they happen, which is efficient for infrequent events. The trade-off is that your server must be reachable from the internet, and you must handle the cases where a delivery is missed. Many teams combine both methods, using webhooks for speed and a periodic check to catch anything that was not delivered.
If an application needs a continuous two-way connection instead, the technique is different. See WebSockets.
Signatures, Retries and Duplicate Events
Anyone who learns your webhook URL could send fake requests to it, so providers usually sign each delivery. The provider calculates a signature from the request body and a secret shared with you, and sends it in a header. Your server recalculates the value and rejects the request if the two do not match. Verifying signatures is the main defense against forged events.
Delivery is not guaranteed on the first attempt. If your server is down or returns an error, the provider typically retries, often with increasing delays. As a result, the same event can arrive more than once. Receivers should respond quickly with a success status, do heavy work in the background and treat duplicates as normal, usually by recording the ID of each event they have already processed.
Frequently asked questions
Do webhooks require a public server?
Yes, the receiving end must be reachable over the internet, because the provider sends each request to a public URL. A server behind a firewall or on a private network cannot receive webhooks unless it is reachable through an exception, a relay or a tunnel. During development, temporary tunneling tools are often used for this reason.
What happens if a webhook is lost?
Providers usually retry failed deliveries for a limited time, but a delivery can still be missed if your endpoint stays down longer than the retry period. Reliable systems record each incoming event, process it safely and run a periodic sync against the provider's API so that any gaps are found and filled.