429 from the Clerk Backend API: which limit you hit and how to back off

Symptom

Backend API calls return 429 Too Many Requests, often during bulk work (imports, syncs, metadata updates).

Confirm the cause

1. Read the Retry-After response header on the 429. It tells you how many seconds the block lasts.
2. Know your tier: development instances allow roughly 100 requests per 10 seconds; production roughly 1000 per 10 seconds. Special endpoints are stricter (invitations per hour, metadata updates per user or org per 10 seconds).
3. If you only 429 on development, that is expected: dev limits are 10x lower. Do not "fix" it by hammering harder.

Fix

• Honor Retry-After, then back off with jitter and retry.
• Paginate list calls (up to 500 per page) instead of one request per record.
• Cache user and organization reads instead of refetching per request.
• Note the JWKS endpoint is not rate limited, so token verification traffic is not your culprit; look at Backend API call volume.

Verify

After adding backoff and batching, the same workload completes without 429s, and your logs show Retry-After being honored when limits are hit.

Verified against Clerk's rate-limits docs 2026-09-26: 429 means rate limited with a Retry-After header giving the block duration in seconds; roughly 1000 req/10s on production instances and 100 req/10s on development; stricter per-endpoint limits (invitations, metadata updates); the JWKS endpoint carries no rate limit.