# 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.