Webhook Fundamentals
How Webhooks Work
Webhooks allow systems to send real-time notifications when events occur. They are widely used by platforms like Stripe, Paddle, and GitHub to inform applications about payments, subscriptions, deployments, and other important events.
At a high level, webhooks are simple: one system sends an HTTP request to another system when something happens.
But in production systems, webhook delivery involves multiple steps including retries, signature verification, background processing, and error handling.
Understanding the full lifecycle of a webhook event helps developers design more reliable integrations.
The basic webhook flow
A typical webhook interaction looks like this:
- An event occurs in the provider system
- The provider creates an event payload
- The provider sends an HTTP POST request to your webhook endpoint
- Your server validates the request
- Your application processes the event
- The server returns a 2xx response to confirm delivery
If the endpoint responds successfully, the event is considered delivered.
What happens when webhook delivery fails
If your endpoint does not return a successful response, the provider usually retries the delivery.
For example, Stripe retries failed webhook deliveries for several hours using exponential backoff.
Retries help reduce the risk of event loss, but they introduce new challenges such as duplicate processing.
Why webhook handlers must be idempotent
Because webhook providers retry failed deliveries, your system may receive the same event more than once.
Webhook handlers must therefore be idempotent — meaning that processing the same event multiple times does not cause incorrect behavior.
This is usually implemented by storing the event ID and ignoring duplicates.
See our guide on idempotent webhook handling in Laravel.
Why webhook handlers should respond quickly
Webhook endpoints should respond as quickly as possible. If the request takes too long, the provider may treat the delivery as failed and retry the event.
A common architecture is:
- validate the webhook request
- store the event
- dispatch background processing
- return HTTP 200 immediately
This design reduces the chance of timeouts and duplicate events.
Why monitoring webhook activity matters
Webhook integrations often fail silently. The main application may appear healthy while webhook events are failing or retrying in the background.
Monitoring webhook response codes, response times, and retry patterns helps detect problems before they affect production systems.
Key takeaways
- Webhooks deliver events using HTTP requests
- Providers retry deliveries when failures occur
- Webhook handlers must handle duplicate events
- Background processing improves reliability
- Monitoring helps detect failures early