Webhook definition
A webhook is an HTTP request that one system sends automatically to a URL you provide when a specific event happens, such as a payment succeeding or a form being submitted. Instead of your app repeatedly asking for updates, the other service pushes the event to you in near real time, usually as a JSON payload.
How do webhooks work?
You register an endpoint URL with the provider and choose which events you care about. When an event occurs, the provider sends an HTTP POST to that URL with a JSON body describing it: the event type, an ID and the related object. Your server verifies the request, records it and returns a 2xx status quickly. If it does not, most providers retry with increasing delays for hours or even days.
Webhooks are sometimes called reverse APIs or push APIs. They complement a normal API: the webhook tells you that something happened, and you often call the API afterward to fetch full details, confirm the current state or take the next action.
Webhook vs API polling
Without webhooks, your app would poll, asking every minute whether anything changed. Polling wastes requests when nothing happens and still delays updates by up to the polling interval. Webhooks deliver events within seconds and only when there is something to report. The trade-off is that you must run a public endpoint that is always available, and you must handle duplicate, delayed and out-of-order deliveries gracefully. For most integrations between companies that trade-off is clearly worth it.
Webhooks also differ from WebSockets. A webhook is a one-off server-to-server HTTP call per event, ideal for integrations between companies. WebSockets keep a long-lived connection open to a browser or app for live updates such as chat or dashboards. Many systems use webhooks to receive events from a provider and WebSockets to push them on to users.
Common webhook examples
Most providers let you choose which event types to subscribe to and offer a dashboard showing every delivery attempt, its payload and your server response, which is the first place to look when an integration misbehaves. Typical webhook sources include:
- Stripe and Razorpay send payment succeeded, failed and refunded events so orders update without the customer waiting
- GitHub sends push and pull request events that trigger CI pipelines and deployment bots
- Shopify sends order and inventory events to ERPs and fulfillment systems
- The WhatsApp Business Platform sends incoming messages and delivery receipts to chat backends
- Twilio sends call status updates and SMS replies to your application
- Form and scheduling tools such as Typeform and Calendly notify CRMs when someone submits or books
Securing and processing webhooks reliably
Treat every webhook as untrusted until verified. Providers sign payloads with a shared secret, typically an HMAC SHA-256 signature in a header, and include a timestamp; check both to block forged and replayed requests. Accept HTTPS only, and never trust amounts or statuses in a payload without validating them against the provider's API when money is involved.
For reliability, acknowledge fast and process asynchronously: store the event, return 200, then handle it from a message queue. Because retries create duplicates, make handlers idempotent by recording processed event IDs. Nexzem builds webhook pipelines this way for payment, chat and ERP integrations, with dashboards that surface failed deliveries.