Anthropic's Messages API can return either a 429 status with a `rate_limit_error` type or a 529 status with an `overloaded_error` type. According to Anthropic's documentation, what is the practical difference between these two conditions?
- a 429 with a `rate_limit_error` type means the calling organization's own limits, such as a requests-per-minute cap or a configured spend limit, have been exceeded, while a 529 with an `overloaded_error` type means the API itself is temporarily overloaded across all users, a capacity condition unrelated to that organization's own usage
- 429 and 529 both describe exactly the same underlying condition, and application error-handling code does not need to distinguish between them
- a 529 status means the calling application's API key has been revoked, while a 429 status means the request body was malformed and rejected by validation
- a 429 status can only ever be returned by the Batch API, while a 529 status can only ever be returned by the standard synchronous Messages API, so the two are distinguished solely by which endpoint returned them
Why A? And why not the others?
Correct answer: A. a 429 with a `rate_limit_error` type means the calling organization's own limits, such as a requests-per-minute cap or a configured spend limit, have been exceeded, while a 529 with an `overloaded_error` type means the API itself is temporarily overloaded across all users, a capacity condition unrelated to that organization's own usage
Anthropic's documented error reference ties `rate_limit_error` specifically to the 429 status, describing it as the organization having hit its own rate limit, usage-tier spend cap, or a workspace-specific spend limit, while it ties `overloaded_error` specifically to the 529 status and explains that this happens when the API experiences high traffic across all users, a shared-capacity condition rather than anything the calling organization did. Treating the two as interchangeable is wrong because they point to different root causes with different appropriate responses, even though both can warrant retrying with backoff. Describing 529 as a revoked key and 429 as malformed input is wrong because those conditions are documented separately as 401 `authentication_error` and 400 `invalid_request_error` respectively, not as 429 or 529. Restricting each code to a single specific endpoint is wrong because both status codes are documented as general API-wide conditions, not endpoint-specific ones.
Source: Anthropic, API errors documentation, https://platform.claude.com/docs/en/api/errors