A webhook gateway is a service that sits between the systems sending webhooks and the endpoints that process them. It gives providers one stable URL, verifies and stores every incoming webhook, then delivers it to one or more destinations with retries, rate limiting, filtering, transformation and logs. Your application receives clean, reliable deliveries and doesn't have to solve delivery problems itself.
Stripe ─┐ ┌──▶ billing service (retries, 30 days)
GitHub ─┼──▶ webhook gateway ──store──route─┼──▶ localhost / on-prem (via agent)
Shopify ┘ verify · log · throttle └──▶ Slack #alerts (transformed)
What a webhook gateway does
| Capability | What it solves |
|---|---|
| Stable ingestion URL | Providers point at the gateway once. You move or add backends without touching their settings. |
| Persistence | Each webhook is stored before delivery, so a crash or outage on your side doesn't lose it. |
| Retries with backoff | Failed deliveries are retried with exponential backoff on a schedule you control, not the provider's. |
| Authentication | Verify each provider's signature at the edge and drop forged requests. |
| Fan-out and routing | Deliver one event to several destinations, or route by event type. See webhook fan-out. |
| Throttling | Release events at a rate or concurrency your endpoint can handle, so bursts don't turn into 429s or 503s. |
| Transformation and filtering | Reshape the payload for the destination, or drop events nobody needs. |
| Observability and replay | One log of every request and response, with replay after an incident. |
Webhook gateway vs API gateway vs reverse proxy
| Reverse proxy | API gateway | Webhook gateway | |
|---|---|---|---|
| Traffic | Any HTTP | Synchronous API calls | Asynchronous events |
| Stores requests | No | No | Yes |
| Retries later | No | No | Yes, for hours or days |
| Fan-out | No | Rarely | Yes |
| Response to caller | Your server's | Your server's | Usually an immediate acknowledgement |
| Examples | nginx, Caddy, Traefik | Kong, AWS API Gateway, Apigee | Webhook Relay, Hookdeck, Convoy |
A reverse proxy or API gateway in front of your webhook endpoint helps with TLS and routing, but if your service is down, the request fails with a 502 or 504 and you depend on the provider to try again. A webhook gateway accepts the event and takes over responsibility for delivering it.
When you need one
- Lost webhooks are expensive. Payments, orders, provisioning and security alerts.
- Provider retry windows are too short. GitHub doesn't retry automatically, and many providers give up after minutes or a few days.
- Several services need the same events, but the provider allows one URL.
- The receiver has no public IP: on-prem systems, Kubernetes clusters, CI servers or a developer laptop.
- Bursts overload the endpoint during sales, batch jobs or replays.
- You want one place to debug instead of a dashboard per provider.
If you only receive a handful of low-stakes webhooks on a public server that's always up, a gateway is optional. An idempotent endpoint that queues events may be enough.
Inbound vs outbound gateways
An inbound webhook gateway receives webhooks from third parties for your systems. An outbound gateway, often called webhooks as a service, sends your events to your customers' endpoints, handling signing (often with Standard Webhooks), per-customer retries, endpoint health and replay. Webhook Relay does both: the webhook gateway for inbound, and the Outbound Gateway for sending.
Webhook Relay as a webhook gateway
Webhook Relay persists every event the moment it arrives and retries with exponential backoff for up to 30 days (durable retries). It can verify signatures, throttle delivery, deliver one webhook to up to 200 destinations, reshape payloads with transform functions, and log every delivery with one-click resend and replay. Its distinguishing feature is delivery to internal servers: relay forward runs an agent that opens an outbound connection, so webhooks reach localhost, on-prem and private Kubernetes services with no public IP or open port. See receiving webhooks on localhost to try it, or the webhook gateway overview for the full feature set and a comparison with other gateways.