Why You're Getting 429s in Production Using Auth0 and How to Stop Them

Summary

Auth0 429 responses in production are tied to rate limits, commonly when applications call the Management API for every request or obtain a new machine-to-machine (M2M) token for every request. Because limits are per tenant and vary by plan, logging x-ratelimit-limit, x-ratelimit-remaining, and x-ratelimit-reset headers exposes approaching exhaustion. User roles, permissions, and metadata that can be treated as access-token snapshots should be added as custom claims by a Post-Login Action, while APIs read them from the JWT. M2M tokens, valid for 24 hours by default, should be cached and refreshed with a 60-second expiry buffer; data requiring freshness should sit behind a server-side cache with a 30-to-60-second TTL. When a 429 occurs, retry at the Unix timestamp in x-ratelimit-reset rather than applying exponential backoff, because the reset time is deterministic.

Takeaways

1. 1

   Each service should have its own M2M client to provide more control over least-privilege access, credential rotation, and observability.

2. 2

   Email verification status, newly changed organization membership, and MFA enrollment are examples of data that may require current checks rather than token claims.

3. 3

   Auth0's x-ratelimit-reset value is a Unix timestamp, so the retry delay can be calculated directly instead of using exponential backoff.