Fix HTTP 429 Too Many Requests
A 429 response says a request budget was exceeded. Slow the caller deliberately, identify the budget scope, and prevent retries from turning normal throttling into an outage.
Read the response contract
Capture the status, Retry-After, documented rate-limit headers, request identifier, and a redacted error body. Retry-After can contain either seconds or an HTTP date. Provider-specific headers may describe a remaining count and reset time, but their names and semantics vary. Do not infer a universal algorithm from one header.
Back off with jitter
If Retry-After is present and reasonable, wait until that time. Otherwise use bounded exponential backoff and add random jitter so many clients do not retry simultaneously. Limit both attempts and total elapsed time. Interactive requests should fail clearly after a small budget, while a background queue can reschedule work without holding a thread or connection open.
Retry only safe operations
GET requests are usually repeatable, but a POST may create a duplicate when the first response was lost after the server accepted it. Use documented idempotency keys for creation and payment operations. Preserve the same key across retries. Never assume a timeout or 429 proves that no state changed, especially when a gateway and application use separate limits.
Coordinate concurrency
Independent workers can each believe they are within budget while their combined traffic overwhelms one account, token, tenant, IP address, or endpoint. Apply a shared limiter before requests leave the process or queue. Bound parallelism, batch when supported, cache stable results, collapse duplicate work, and stop polling when event-driven updates are available.
Find unexpected request volume
Measure requests by endpoint, caller, tenant, outcome, and retry attempt without logging credentials or private bodies. Common causes include an accidental loop, UI rerenders, missing cache, a scheduler running twice, webhook echoes, and every worker refreshing the same token. The correct fix may reduce traffic rather than purchase a larger quota.
Test recovery
Simulate a 429 with both Retry-After forms, missing headers, and repeated throttling. Verify delay bounds, jitter, cancellation, idempotency, and a useful terminal error. Inspect copied response fields with the HTTP Header Analyzer, but use the provider documentation as the authority for its limits.
Frequently Asked Questions
Should every 429 be retried immediately?
No. Respect Retry-After or use bounded backoff with jitter.
Is Retry-After always seconds?
No. It can also be an HTTP date.
Can parallel workers worsen limits?
Yes. Coordinate a shared request budget.