Webhooks
Also: HTTP callbacks, event notifications
What is Webhooks?
Webhooks are HTTP requests a system sends to a subscriber's URL when an event happens, such as a payment succeeding or an order shipping, so other systems react in real time without polling.
What Webhooks means
A webhook is a push notification between servers. The sending system lets a subscriber register a URL and choose event types; when an event occurs, it POSTs a signed JSON payload to that URL. The subscriber acknowledges with a 2xx response. If delivery fails, the sender retries with backoff for a period, then marks the delivery as failed and, in a good implementation, lets the subscriber replay it.
The engineering that separates reliable webhooks from flaky ones is unglamorous: signing payloads so receivers can verify the source, idempotency keys so retries do not cause duplicate side effects, ordered or at-least-once delivery semantics that are documented honestly, a delivery log the subscriber can inspect, and a dead-letter queue for repeatedly failing endpoints. Consumers, for their part, should acknowledge quickly and process asynchronously.
Webhooks are the outbound half of a platform's integration story; the API is the inbound half. They are not a message bus for internal services and not a substitute for polling when the consumer cannot expose a public endpoint.
Who it really matters to
- CTO / Head of Engineering: retries, signing and idempotency are where webhook integrations break in production, usually months after launch.
- Product manager: webhooks let customers connect your product to their own tools, which increases stickiness.
- Operations head: real-time events replace batch syncs that leave order, payment and delivery data hours out of date.
- Support manager: a delivery log customers can see turns "we never got the event" tickets into self-service.
Why it exists
Webhooks exist because polling wastes resources and introduces lag, and because most business processes span more than one system. A payment confirmed in one place needs to update an order, notify a customer and trigger fulfilment elsewhere within seconds. The trade-off is that the sender now owns delivery reliability and the receiver owns idempotency; both need logging and retry logic. Done casually, webhooks cause duplicate orders and silent gaps; done properly, they are the backbone of a platform.
Where it is applied
- A SaaS product emitting events such as record.created and user.invited so customers can automate their workflows.
- A payment gateway notifying a lending platform that an EMI collection succeeded or failed.
- A logistics platform pushing shipment status changes to a retailer's order system and WhatsApp notifications.
- A learning platform sending course completion events to an institution's records system.
- A hospital scheduling system notifying a voice agent service that an appointment was cancelled so it can offer the slot.
Is Webhooks a skill?
Technique / practiceAn integration pattern implemented in your own product, with supporting tooling for queues and delivery logs. Eazyware builds outbound webhook systems and inbound consumers under the API development and integrations service.
Eazyware service that covers it: API Development & Integrations. Starting prices are on the pricing page.
Frequently asked questions
What must a webhook consumer do to be safe?
Verify the signature, return a 2xx response immediately, process the event asynchronously, and use the event's unique identifier to ignore duplicates. Assume at-least-once delivery and out-of-order arrival unless the sender explicitly guarantees otherwise.
What should a webhook sender provide?
Signed payloads, retries with backoff, a per-subscriber delivery log with replay, clear documentation of event types and delivery guarantees, and a way to disable endpoints that fail repeatedly. Without these, integrations become a support burden.