Webhook rate limits: handling 429 and throttled deliveries

A 429 on a webhook means your endpoint told the provider to slow down. Unlike a 500, nothing is broken — you are shedding load on purpose. What matters is what happens to the deliveries you rejected, and whether you can see which ones they were.

What a 429 means

429 Too Many Requests is a deliberate signal: the request was valid, but you are over a limit and are asking the caller to back off. Providers treat it differently from a 5xx — a 429 says "try again later", not "something failed". Many will honour a Retry-After header if you send one.

Provider retry behaviour

Most providers back off and retry a rate-limited delivery, often respecting Retry-After, for a limited window. So a brief burst that trips your limiter usually recovers on its own — the provider re-sends and the retry lands once the spike passes. The risk is a sustained overload: if you keep returning 429 past the provider’s retry window, those deliveries are dropped just like any other unrecovered failure.

Endpoint rate limits

Rate limits usually come from one of three places: your own application limiter, a gateway or CDN (e.g. an edge WAF) in front of the endpoint, or an upstream dependency the handler calls. Webhook traffic is bursty by nature — a provider can send a batch of events at once — so a limit tuned for human traffic can throttle a legitimate spike of deliveries.

Retry vs drop

The trade-off when you are over capacity:

• Return 429 with Retry-After — cooperative back-pressure; the provider retries later and the event is not lost, as long as it recovers inside the retry window.
• Accept and queue — return 200 fast and buffer the work internally, so you never rely on the provider to retry. Best when you can absorb the burst.
• Drop — the failure mode to avoid: silently rejecting past the retry window loses events with no record of which ones.

How HookWatch keeps throttled deliveries visible

HookWatch records every delivery with its response status, so 429 deliveries show up as their own state in the delivery feed — you can see exactly which events were rate-limited, whether a later attempt succeeded, and which never recovered. The ones that fell outside the provider’s retry window are still captured, so you can replay them once you have headroom. For 5xx failures, see webhook 500 errors.