Webhook 429: rate-limited deliveries explained
A 429 is your endpoint throttling the provider. What happens next depends on the provider’s retry policy — and whether you can see what was throttled.
A 429 means your endpoint told the provider
to slow down — the delivery hit a rate limit (yours, a proxy’s, or your framework’s) before your handler
ran. What happens next is up to the provider’s retry policy.
What the provider does
- Most providers treat 429 as retryable and back off, retrying for a bounded window.
- Some honour a
Retry-Afterheader if you send one — return it to ask for a specific delay. - After the retry window is exhausted, the delivery is dropped. That is the real risk.
Retry vs drop
A burst of events (a backfill, a batch job) can trip the limit and, if retries run out, quietly lose events. Options: raise the limit for the webhook path, smooth spikes with a queue, or accept-and-enqueue fast so the limiter never trips. See handling webhook rate limits.
Keep throttled deliveries visible
In HookWatch, rate-limited deliveries show as a distinct state with their attempts, so a throttling spike is visible instead of silent — and you can replay any that were dropped. Set up monitoring to get alerted when 429s climb.
Keep reading
Start debugging your webhooks.
Point one endpoint at HookWatch, capture a failure, and replay it once it’s fixed. Free during beta.