Under load you get some 429 and some 529 responses. Which statement is right?
Why A is the answer
429 is your rate limit and 529 means the API is overloaded
429 rate_limit_error is about your limits or spend cap. 529 overloaded_error means the API is temporarily overloaded. Both are worth retrying with backoff.
In detail
- 429 rate_limit_error is about your limits or spend cap.
- 529 overloaded_error means the API is temporarily overloaded.
- Both are worth retrying with backoff.
- Track them apart, because they call for different follow-ups.
Use case
An illustrative scenario, not a real incident.
A dashboard groups 429 and 529 as "API down". Separating them shows that the 429s come from one noisy job, while the 529s are brief and clear with backoff.
See it in different ways
flowchart TD
A{"Which status?"} -->|"429, 500, 529"| B["Back off with jitter and retry"]
A -->|"400, 401, 403, 404, 413"| C["Fix the request or credentials"]
B --> D{"Still failing?"}
D -->|Yes| E["Contact support with the request ID"]mindmap
root((API errors))
400
Invalid request
401
Bad key
403
No access
429
Rate limit
529
Overloadedmindmap
root(("Retryable errors"))
n1["429"]
n2["Your rate limit or spend cap"]
n3["Reduce or spread your load"]
n4["529"]
n5["API temporarily overloaded"]
n6["Back off and retry"]Key point: 429 is about your limits, and 529 is about API load.
Why the other options are wrong
- B. Both mean your API key is invalid
- A bad key returns 401.
- C. 529 means your request body was too large
- A 529 is about API load, not your request size.
- D. Both come from your monthly spend cap, so neither one is safe to retry
- A 529 is not about your spending, and both can be retried with backoff.

