What is a webhook receiver?
The webhook receiver is the system that accepts webhook deliveries — your application, an inspector, or a forwarder. A receiver has five jobs: accept the request (HTTP server, public URL, valid TLS), verify the signature so the request is provably from the claimed source, deduplicate by event ID so retries don't double-process, persist the event durably before acknowledging, and acknowledge with HTTP 2xx so the source stops retrying. Receivers can be chained — WebhookWhisper captures inbound deliveries and forwards copies downstream — but the chain must preserve raw bytes, since reserialization breaks signature verification.
The receiver is on the other end of the wire from the source. In a typical Stripe integration, your backend is the receiver. In a development setup using a tool like WebhookWhisper, the inspector is a receiver that forwards to your laptop's localhost server, which is a downstream receiver.
A receiver has five jobs. Accept the request (HTTP server, public URL, valid TLS). Verify the signature so the request is provably from the claimed source. Deduplicate by event ID so retries don't double-process. Persist the event durably before acknowledging it. Acknowledge with HTTP 2xx so the source stops retrying.
What a receiver does after acknowledging is not the source's concern. The clean shape is: receive, persist to a queue, return 200, hand off to a worker. The worker reads from the queue and runs the actual business logic — sending emails, updating databases, calling other services. This split matters because business logic can fail; the receive step shouldn't. If your receive step does business logic synchronously, every flaky downstream service becomes a webhook timeout, which becomes a retry, which compounds load.
Receiver placement varies. Production: usually a public HTTPS endpoint behind a load balancer. Staging: similar but sometimes auth-gated. Development: a localhost server made public via a tunnel like ngrok, or a forwarding service like WebhookWhisper that gives you a stable public URL plus full inspection. Testing: a local recorder that asserts on what your code under test would have sent.
Receivers can be chained. WebhookWhisper, for example, is a receiver that captures the inbound delivery and then forwards a copy to one or more downstream receivers (your localhost, your staging server). When chaining, the chain must preserve the raw body byte-for-byte — any reserialization breaks signature verification at the downstream receiver. WebhookWhisper does this; some naïve forwarders (and any "parse and re-emit JSON" approach) silently break it.
If you are building a multi-tenant SaaS that receives webhooks on behalf of customers, you are operating a fleet of receivers, one per customer endpoint. The hardest part is not accepting requests — it is keeping every one of those endpoints publicly reachable, properly signed, and observable, indefinitely.
See Webhook Receiver in real traffic
WebhookWhisper captures every webhook with full headers, body, signature, and timing — so concepts like webhook receiver stop being abstract and become something you can inspect.
Start Free