Webhook Throttling

Traffic doesn't arrive politely. Webhooks come in bursts — and a burst that's harmless to Webhook Relay can flatten the server on the other end. Throttling lets you set the pace.

The problem: spikes don't ask permission

A quiet integration can turn into a flood without warning. A provider replays a backlog, a sale goes live, a batch job fires thousands of events at once. Webhook Relay absorbs that spike without breaking a sweat — but your destination might not. The result is familiar: timeouts, 429s, a database pegged at 100%, and a cascade of failures that takes out more than just the webhook endpoint.

The usual fixes are all work: stand up a queue, add workers, write the backpressure logic, tune it, then babysit it.

The solution: deliver at a pace you control

Throttling puts a governor between Webhook Relay and your destination. Instead of delivering the instant an event arrives, Webhook Relay holds each webhook safely and releases it at the speed you set — turning a jagged spike into a smooth, predictable stream your server can actually handle.

Two ways to set the pace

• Rate — deliver at most N webhooks per second, minute or hour. Set it to whatever your endpoint (or a downstream API's rate limit) can take, and Webhook Relay never goes over.
• Concurrency — cap how many deliveries are in flight at once. Set it to 1 for strictly one-at-a-time delivery, or to a handful to match exactly how much parallel load your service can handle.

Either way, nothing is thrown away to keep the pace. Throttled webhooks wait their turn in order, oldest first, and go out the moment there's room.

Backpressure when you need it

Add an optional queue limit and Webhook Relay will push back at the source — returning a standard 429 Too Many Requests once a destination's queue is full, so a runaway sender slows down instead of building an endless backlog. Anything still waiting past its deadline is cleaned up automatically, so queues never rot.

Protects every destination

Throttling works the same for public HTTPS endpoints and for internal services reached through the Webhook Relay agent — especially handy when the thing you're protecting is a small service on your own infrastructure.

Where it earns its keep

• Fragile or legacy endpoints. That internal service which falls over above 20 requests a second? Cap it at 20 and stop worrying.
• Downstream rate limits. Forwarding into an API that allows 100 calls a minute? Match it exactly and never get rate-limited again.
• Big bursts, small servers. A flash sale or a webhook replay shouldn't decide whether your server stays up.
• Fair sharing. Give each destination its own budget so one slow consumer can't starve the rest.

Better together with durable retries

Throttling decides how fast; durable retries decide how long. Turn on both and retries to a recovering endpoint respect the same speed limit as fresh traffic — so you never accidentally finish off a server that's only just getting back on its feet.

Ready to take control of your throughput? Create a free account and add throttling to your first destination.