# Fix Auth0 SCIM provisioning failing on Management API 429s

## TL;DR
Auth0's SCIM provisioning path calls the Management API, which enforces strict per-minute rate limits. When a sync exceeds that budget it 429s and provisioning tasks fail. This is a throughput problem, not a credentials problem: slow the sync with smaller batches, fewer mapped attributes, and backoff on 429, and schedule bulk syncs off-peak. Do not retry 429s aggressively.

## The error
```text
SCIM provisioning error: Management API rate limit exceeded (429)
Auth0 Dashboard / Monitoring / Logs: "Rate limit exceeded" / "Global rate limit exceeded" on /api/v2/users
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=auth0%20scim%20provisioning%20failed%20management%20api%20429%20rate%20limit"
```

## Fix it

### Step 1: Confirm the 429s line up with SCIM sync windows

```bash
In Auth0 Dashboard / Monitoring / Logs, search for rate-limit log types and compare timestamps against the SCIM provisioning schedule.
```

Expected: 429 spikes align with sync runs. If they do not, some other API consumer is the culprit - find it before changing the sync.

### Step 2: Reduce the per-sync API cost

```bash
In the SCIM provisioning attribute mapping, drop every attribute the target app does not need. Narrow the assigned user set so each cycle touches fewer users.
```

Expected: fewer Management API calls per sync cycle.

### Step 3: Add backoff to any custom SCIM bridge code

```bash
On HTTP 429, wait the Retry-After seconds (or exponential backoff with jitter starting at a few seconds) before retrying, and cap retries per cycle.
```

Expected: retries spread out instead of bursting, so a single 429 does not cascade into hundreds.

### Step 4: De-conflict with other API consumers

```bash
Schedule bulk SCIM syncs off-peak and stagger them away from other heavy Management API users: user imports, log-stream backfills, rules or actions that call the API.
```

Expected: two bursty consumers no longer share the per-minute budget.

### Step 5: Request a limit increase if the need is sustained

```bash
If the sync legitimately needs more throughput after steps 2-4, open an Auth0 support request with log evidence showing the 429 pattern and the business need.
```

Expected: support adjusts the tenant's rate limits or confirms the current ceiling so you can size the sync to it.

## When this applies

- SCIM provisioning fails with 429 during sync windows
- Auth0 logs show rate-limit errors on Management API endpoints
- Failures are intermittent and correlate with bulk operations

## When it doesn't

- The failure is 401 or 403 (credentials or permissions)
- Failures are constant, not bursty (look for a config error)
- A single user fails while the rest succeed (per-user issue)

## Compatibility

Auth0 (Okta Customer Identity Cloud) SCIM provisioning; Management API v2 rate limits. Notes apply to any tenant with bursty API consumers.

## Variant phrasings

### auth0 scim 429 too many requests

Same fix. Check whether the SCIM sync or something else owns the burst before throttling the sync.

### management api rate limit provisioning auth0

The Management API budget is per tenant, shared across all consumers. Provisioning is just one of them.

## Why it happens

Auth0 enforces per-tenant per-minute quotas on the Management API. SCIM bulk operations are bursty by nature - hundreds of user reads and writes in a tight window - so a sync that fits the daily average can still blow the per-minute budget. The 429 is the API protecting itself.

## Edge cases

- A 429 and a 403 look similar in logs; confirm the status code before throttling
- Some endpoints (like the search-heavy ones) have lower effective limits than the documented defaults
- Log streams and SIEM exporters can be hidden API consumers eating the budget

## If it still fails

- Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
- Reproduce with a single test user so you are not debugging a crowd.
- If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

## Prevention

- Track credential and certificate expiry with alerts, not memory.
- Run a synthetic check per app daily so breakage pages you, not a user.
- Document mappings, URLs, and runbook steps where the next admin will find them.

## Provenance

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