Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Last reviewed: February 20, 2026|Editorial standard: source-backed comparison guidance
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
{
"error": "too_many_requests",
"message": "Rate limit exceeded for api_key_123.",
"limit_scope": "api_key"
}HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 120
{
"error": "service_unavailable",
"message": "Service is temporarily unavailable due to maintenance.",
"status_page": "https://status.example.com"
}No. Use 429 when a caller cohort exceeds policy limits. Use 503 when the service is broadly unavailable independent of one caller identity.
They can. Include `Retry-After` when you can provide a meaningful retry window, and ensure clients treat it as an upper-bound pacing signal.
Only with bounded, jittered retries and idempotent operations. Unbounded retries on either status can amplify load and prolong incidents.
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.