What is a webhook gateway?

A webhook gateway sits between source providers and your real handlers. Inbound webhooks land at the gateway's URL; the gateway authenticates, persists, and forwards to your downstream services. Hookdeck, Svix's inbound product, and WebhookWhisper's forwarding feature are all webhook gateways.

What a gateway does that a plain receiver doesn't:

- Persistent receive. The gateway always returns 200 fast (because it just persists the event), so source-side retry pressure stays low even when your downstream is slow. - Fan-out. One inbound webhook can forward to multiple destinations — your prod service, your staging service for replication, an analytics pipeline — without each destination registering separately with the source. - Filtering and routing. Gateway-level rules can route specific event types to specific downstreams. charge.succeeded → billing service; customer.created → CRM service. - Replay. Past events can be re-sent to a downstream after a bug fix, without asking the source to redeliver. - Local development bridge. The gateway gives you a stable public URL during dev; events forward to your laptop's localhost. This is the WebhookWhisper wedge. - Centralized observability. All webhook traffic is in one place — searchable, alertable, debuggable — instead of fragmented across each downstream service's logs.

What a gateway must preserve to be safe:

- Raw body byte-for-byte. Downstream signature verification requires the exact bytes the source sent. A gateway that parses-and-reserializes silently breaks signature verification at every downstream. The gateway must store and forward the raw bytes verbatim. - Headers verbatim. The signature header, the event ID header, the timestamp — all must reach the downstream unmodified. - At-least-once forwarding. If the downstream is down, the gateway retries on its own schedule. Events should not be silently lost between gateway-receive and gateway-forward.

When a gateway makes sense:

- You receive webhooks from many sources to many destinations and want one place to manage it. - You want local development without re-registering URLs each session. - You want replay capability the source doesn't offer. - You're operating multi-tenant SaaS and customers bring their own webhook sources.

When a plain receiver is sufficient:

- One source, one destination, simple integration. The gateway adds a hop without earning its keep. - Latency-sensitive flows where adding a hop adds milliseconds you can't spare. - Compliance contexts that prohibit in-flight data in third-party services.

Building one in-house is non-trivial — durable storage, retry logic, observability, multi-tenancy — but for narrow use cases (one team, one source) a 200-line forwarder over Postgres is enough.