Webhooks
Webhooks are HTTP callbacks that push event notifications from a producer to a consumer's pre-registered URL when specific events occur, enabling real-time server-to-server integration without polling.
A webhook is a user-defined HTTP callback. You register a URL with a service, and when an event happens (payment completed, PR merged, order shipped), the service sends an HTTP POST to your URL with event data as the JSON body. It's like saying "call me when something happens" instead of constantly asking "has anything happened yet?" Webhooks are server-to-server (not browser-facing), require no persistent connections, and are the standard integration pattern for services like Stripe, GitHub, Twilio, and Shopify.
Strengths
- Real-time event delivery without polling — consumers are notified immediately when events occur
- Simple HTTP-based protocol — no special infrastructure, just standard HTTP POST requests
- Decoupled architecture — producer and consumer are loosely coupled with no persistent connection
- Universal adoption — virtually every SaaS platform supports webhook integrations
- Resource efficient — no wasted requests checking for changes that haven't occurred
- Easy to implement on the provider side — standard HTTP client libraries in any language
Weaknesses
- Consumer must host a publicly accessible HTTPS endpoint — doesn't work for mobile apps or serverless with cold starts
- At-least-once delivery means duplicate events are inevitable — consumer must implement idempotency
- Events may arrive out of order, requiring careful state management and reconciliation
- No built-in backpressure — high-volume webhooks can overwhelm the consumer's endpoint
- Debugging is difficult — tracing a failed webhook through provider retries and consumer processing is complex
- Security requires careful implementation of signature verification to prevent event spoofing
Technical Profile
Latency Profile
Webhook delivery latency is typically 1-30 seconds from event occurrence to HTTP POST delivery, depending on the provider's delivery pipeline. Most major providers (Stripe, GitHub) deliver within 5 seconds under normal conditions. Failed deliveries trigger retries with exponential backoff, potentially delaying delivery by minutes to days. Consumer-side processing latency depends on the async queue architecture — typically milliseconds to seconds for queue-based processing.
Payload Format
JSON
Browser Support
No
Streaming Support
None
Schema Enforcement
Optional
Ideal Use Cases
- Payment processing notifications (charge succeeded, subscription renewed, dispute created)
- CI/CD pipeline triggers (code pushed, PR merged, build completed)
- SaaS platform integrations (CRM events, e-commerce orders, support tickets)
- IoT device event notifications to cloud backends
- Third-party developer platform integrations (app marketplace events, partner notifications)
Real-World Examples
Webhook events for payment lifecycle (payment succeeded, failed, refunded), subscription changes, and dispute notifications — essential for fulfillment and accounting systems
Webhook events for repository activities (push, PR, issues, releases) powering CI/CD pipelines, chatbot integrations, and automated workflows
Webhook notifications for order events, product changes, and customer updates enabling third-party app integrations and warehouse management systems
Webhook callbacks for SMS delivery receipts, incoming messages, voice call status updates, and recording notifications
Webhook-based Events API for workspace events (messages, reactions, channel changes) powering Slack bot integrations and workflow automations
Likely Follow-Up Questions
- How would you design a webhook delivery system that guarantees at-least-once delivery with retry and dead letter queues?
- Explain how HMAC signature verification prevents webhook spoofing and why constant-time comparison is essential.
- How would you handle webhook events that arrive out of order (e.g., receiving 'shipped' before 'paid')?
- What is the async processing pattern for webhooks, and why should you never process events inline before returning 200?
- How would you prevent SSRF attacks when allowing users to register webhook URLs on your platform?
Related Concepts
Source: editorial — Synthesized from Stripe's webhook documentation, GitHub's webhook guide, the Standard Webhooks specification, and production patterns from webhook infrastructure providers like Svix.