HTTP 429 field note
API 429 Too Many Requests: read the limit before retrying
Distinguish API rate limits, quota exhaustion, concurrency limits, and resource locks from a 429 response and its headers.
A 429 is a limit signal, not a complete diagnosis. Retry-After, provider-specific reason headers, the error body, and the scope of the limit determine whether waiting, reducing concurrency, changing account limits, or serializing one resource is the correct response.
Treat the complete response as an evidence record: status, headers, provider code, request identifier, method, and raw body. The sequence below separates what the response proves from the checks still needed before a safe retry or code change.
Diagnostic procedure
Work from evidence to recovery.
- 01
Identify the limiter
Read the provider error code and reason headers. Account quota, requests per minute, tokens per minute, concurrency, and object locks need different fixes.
- 02
Honor explicit timing
If Retry-After is present, parse delta-seconds or the HTTP date. Do not schedule a guessed retry earlier than the provider permits.
- 03
Make the retry safe
Use a capped jitter strategy and idempotency protection for operations that can create duplicate side effects.
HTTP/1.1 429
Retry-After: 17
{"error":{"code":"rate_limit_exceeded"}}wait = max(parseRetryAfter(headers), backoff(attempt)) retry only if operation is safe or idempotency-protected
- 100
- window limit
- 0
- remaining
- 17s
- Retry-After
- 0
- safe req/s
Precedence Honor Retry-After when supplied. Treat reset and remaining fields as pacing evidence, not permission to burst.
Clock form X-RateLimit-Reset is often epoch seconds; the standardized RateLimit-Reset field may represent delta-seconds depending on the provider implementation.
No account · no upload · no endpoint calledOpen the full rate-limit analyzer and operating notes →
FAQ
Before you ship
Does APITC send this evidence to an API?
No. The matching and calculations in the linked workbench run in the active browser tab.
Should every 429 response be retried?
No. Retry behavior depends on the method, idempotency protection, provider instructions, and whether the failure is temporary.
Protocol behavior checked against the MDN — 429 Too Many Requests. Recheck your pinned provider/API version before production deployment.