Webhooks: Real-Time Event Delivery Explained
Webhooks are a mechanism for APIs to notify your system when something happens — rather than your system repeatedly asking "has anything happened yet?" (polling). When an event occurs (a payment is processed, a form is submitted, a user signs up), the webhook sends an HTTP POST request to a URL you specify, containing details of the event.
Webhooks vs Polling
Without webhooks, to know if a payment has been processed you must poll the payment API repeatedly: "is it done? is it done now? what about now?" — making unnecessary API requests, adding latency, and often hitting rate limits. With a webhook, the payment provider sends you a notification the moment the payment completes — instant delivery, no unnecessary requests.
Common Webhook Use Cases
- Payment providers (Stripe, Braintree) notifying on payment, refund, or dispute events
- E-commerce platforms notifying on order, fulfilment, and return events
- Form tools sending submissions to your CRM
- CI/CD pipelines triggering deployments on code pushes
- Communication platforms (Slack, Teams) delivering message events
Building a Webhook Receiver
A webhook receiver is an HTTP endpoint your application exposes publicly. When called, it must: acknowledge receipt quickly (return a 2xx status within seconds), verify the webhook signature to confirm it came from the legitimate sender, and process the event (or queue it for async processing if it takes time).
Webhook Reliability
Webhooks can fail — your server may be down, return an error, or time out. Good webhook providers retry failed deliveries with exponential backoff. Design your receiver to be idempotent — processing the same event twice should produce the same result as processing it once.