Rate limiting
How to behave politely and handle '429 Too Many Requests' responses
Treat the API as rate limited even if you rarely see 429 Too Many Requests. Good behavior prevents avoidable throttling.
When to retry
Retry only on:
429 Too Many Requests500/502/503(transient infrastructure / upstream)
Do not retry blindly on 400 / 401 / 403 / 404; correct the underlying issue instead.
Handling 429
Check Retry-After. If present, wait that duration (seconds or HTTP-date) plus a small random jitter (0–250 ms). If missing, use full‑jitter exponential backoff (see Retry & backoff). Cap total attempts to e.g. 5, then surface the error.
Proactive slowdown
If latency climbs or 429 frequency increases, lengthen polling intervals instead of waiting for more errors.
Next: Retry & backoff or revisit Requirements.