# The two cases a client must handle 429 + Retry-After: 30 -> sleep 30s, then retry 503 + Retry-After: 5 -> sleep 5s, then retry # No header present? Exponential backoff with jitter: delay = min(base × 2^attempt + random_jitter, max_delay)
Retrying immediately after a 429 compounds the problem and reads as abuse. Production clients centralize this logic in one HTTP wrapper so every call site inherits correct behavior - including a retry budget, so a persistent outage fails fast instead of piling up sleeping workers.
Respect Retry-After on any 429 from credit-metered endpoints (limits are described at /limits). Consumers that keep hitting the ceiling usually want either response caching or streaming delivery instead of tighter polling loops - see rate limit.