HTTP 429 and responsible automation: limits, delays, and retries
A 429 response means the service received too many requests in its chosen time window. The correct response is to slow down, not change IP and maintain the same load.
Key points in one minute
- Honor Retry-After when it is provided.
- Rate-limit by user and business function, not only by IP.
- The operation's aggregate budget matters more than available IP count.
- Retry state needs a deadline and an explicit terminal outcome.
What 429 means
The standard does not mandate one counting method: a limit may apply to an account, resource, cookie, or server cluster.
Before automation, obtain published quotas from the API owner or agree on an internal request budget. Separate limits by account, endpoint, and operation. Track request count, 429 rate, and recovery time, but do not experimentally discover production limits without separate authorization.
Backoff strategy
Use the server-provided delay or bounded exponential backoff with jitter. Set a maximum attempt count.
The retry state should store attempt, nextAttemptAt, and a final deadline. If Retry-After is a date, account for clock synchronization; if it is seconds, use it as a lower bound. Add jitter so many workers do not wake simultaneously. After the attempt limit, expose an explicit failure rather than waiting forever.
Why rotation is not a remedy
Rotating addresses to bypass a limit defeats the protection and may violate service rules. It does not reduce the underlying load.
Do not distribute the same disallowed traffic across additional IP addresses. For legitimate parallel work, cap aggregate intensity by business operation even when each modem has a different address. If 429 rates spike, open a circuit breaker while retaining only very low-frequency authorized health checks.
Observability
Track the 429 rate, affected operations, recovery time, and authorized scenario identifier without logging secrets.
The dashboard should show the current budget, consumed share, next permitted retry, and limit source. Separate client configuration errors from real server-side throttling. Alert only after sustained threshold breaches across several windows so one 429 does not unnecessarily page an operator.
Practical checklist
- 1Support Retry-After.
- 2Cap retry attempts.
- 3Agree on allowed intensity with the service owner.
- 4Add jitter and a maximum deadline.
- 5Configure a circuit breaker for sustained 429 growth.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.