---
title: "Why You're Getting 429s in Production Using Auth0 and How to Stop Them"
description: "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."
---

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

[Auth0](https://yomu.fyi/company/auth0) · Carla Urrea Stabile · Sep 10, 2026

**Type:** Problem & solution

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

## Context

Production 429 responses are associated with Auth0 rate limits, especially when the Management API is called on every application request or a new M2M token is fetched for every request. Management API limits apply per tenant, vary by plan, and can be exhausted as traffic grows.

## Approach / What changed

Move stable authorization data into access-token custom claims with a Post-Login Action, cache and reuse M2M tokens until they approach expiry, and place a short-TTL server-side cache before live Management API lookups. For 429 responses, use x-ratelimit-reset to determine when to retry.

## Takeaways

- Each service should have its own M2M client to provide more control over least-privilege access, credential rotation, and observability.
- Email verification status, newly changed organization membership, and MFA enrollment are examples of data that may require current checks rather than token claims.
- Auth0's x-ratelimit-reset value is a Unix timestamp, so the retry delay can be calculated directly instead of using exponential backoff.

**Tags:** [Auth0](https://yomu.fyi/topic/auth0), [Caching](https://yomu.fyi/topic/caching), [Rate Limiting](https://yomu.fyi/topic/rate-limiting)

- Source: [Auth0](https://auth0.com/blog/why-getting-429s-and-how-to-stop-them)
- Source URL: https://auth0.com/blog/why-getting-429s-and-how-to-stop-them
- Ingested by Yomu: 2026-09-10T16:01:03.735Z

[Read original post](https://auth0.com/blog/why-getting-429s-and-how-to-stop-them)