# auth0 error 429 Too Many Requests: rate limit hit during bulk user import migration

TL;DR: You are creating users one API call at a time and tripping Auth0's Management API rate limits. Switch to the bulk users-import job endpoint - it is built for migrations and replaces thousands of calls with one job. For any remaining per-user calls, add retry with exponential backoff that honors the `Retry-After` response header.

```text
auth0 error 429 Too Many Requests: rate limit hit during bulk user import migration
```

## Steps

1. Confirm what is being throttled: the 429 responses and your import logs show which endpoint is hot (usually per-user create or update).
   Expected: you can name the endpoint eating the rate-limit budget.
2. Switch the import to the bulk path: POST your users file to the Management API's users-import job endpoint instead of looping per-user calls. One job replaces thousands of individual requests.
   Expected: the job is created and returns a job id; its status moves toward completed.
3. For the Management API calls that remain (roles, metadata, app assignments), add retry with exponential backoff that respects the `Retry-After` header on 429 responses.
   Expected: 429s drop to near zero and no users are lost to throttling.
4. Verify: compare the imported user count in Auth0 against the source system.
   Expected: counts match; if not, re-run only the delta.

## Use this when

- 429 Too Many Requests appears during a bulk user migration into Auth0.
- The import script loops over per-user Management API calls.
- Retrying immediately makes the throttling worse.

## Not for this skill when

- The 429s are on the Authentication API during login traffic - different limits, different fix.
- The 429 comes from your own rate limiter in front of Auth0 - fix your limiter config.
- It is a single isolated 429 on one call - just retry that call.

## Variant phrasings

- auth0 too many requests bulk user import
- auth0 management api rate limit during migration
- auth0 import users 429 retry-after

## Why it happens

Each per-user Management API call spends from tight per-minute rate-limit buckets, and a migration loop burns through them in seconds. The import-job endpoint exists precisely to bypass that pattern: it ingests the file server-side instead of charging you per user.

## Edge cases

- The import job is asynchronous - poll its status instead of assuming completion.
- Failed users land in the job's error file - download it and retry just those users rather than the whole batch.
- Keep import files under the job's size limits, or split the source into multiple jobs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_73IkTiJHd1mvueDw_Y1Ytw