# 429 on /oauth/token
## The error
`429 Too Many Requests` from `/oauth/token`, sometimes with a `Retry-After` header. The authentication endpoint rate limits are documented in Auth0's rate limit policy and apply per tenant (burst and sustained).
## Why agents hit it
- M2M code that requests a new client_credentials token on every API call. Tokens live for hours; re-minting per request is pure waste.
- Retry storms: a failing token call retried immediately in a loop multiplies the load.
- Load tests or bulk jobs that authenticate per item instead of per batch.
## Fix
1. Cache the token. Store the access token with its `expires_in`; reuse until ~60 seconds before expiry, then refresh once. A simple in-memory cache with a lock (single-flight) is enough for most services.
2. Back off on 429: honor `Retry-After` if present, else exponential backoff with jitter. Never retry immediately in a tight loop.
3. For user flows, prefer refresh tokens / sessions over re-authenticating.
4. If legitimate traffic exceeds the limits, the answer is request a limit increase or an enterprise tier, not cleverer retries. Check Dashboard > Monitoring > Logs for the rate-limit event types to confirm which endpoint is hot.
## M2M token caching pattern
```
# pseudocode
def get_token():
with lock:
if cached and cached.expires_at - now() > 60:
return cached.value
tok = request_new_token() # single POST /oauth/token
cached = (tok.value, now() + tok.expires_in)
return tok.value
```
## Checklist
- One token per lifetime, not per request.
- 429s back off with jitter and respect Retry-After.