A webhook is an event sent over HTTP
A webhook lets one service notify another service when something happened. Instead of your application repeatedly asking whether a payment completed or a repository changed, the source system sends an HTTP request to a URL you control.
That request usually contains an event name, headers and a JSON body. A payment provider might send payment.succeeded, while a source-control provider might send a push event. Your endpoint accepts the request, verifies that it came from the provider, and performs the work your product needs.
The four pieces of a webhook flow
Every integration has the same basic shape: a producer creates an event, a destination URL receives the request, your application processes it, and the producer records whether delivery succeeded. The last part matters because delivery can fail even when the event itself is valid.
- Producer: the service that publishes an event, such as Stripe, GitHub or Shopify.
- Endpoint: a public HTTPS URL configured with that provider.
- Consumer: the code that validates, queues and processes the request.
- Delivery record: the status, attempts and response that explain what happened.
Why webhook debugging is harder than it looks
The request that failed is often gone by the time you investigate. A log line may omit the raw body, redact the headers you need, or disappear after a short retention window. Local development adds another constraint: a provider on the public internet cannot directly reach localhost on your machine.
A practical webhook workflow preserves the original request, makes delivery state visible, and lets you forward a captured event to a local service. It should also make a safe replay possible when a transient bug has been fixed.
Treat webhooks as production inputs
Webhook handlers should verify signatures before trusting a payload, respond quickly, and move slower work to a queue. They should also be idempotent: providers can retry a request, so processing the same event twice must not create duplicate side effects.
If you can see the exact request, the delivery result and the replay history together, webhook recovery becomes an operational task instead of a guessing exercise.