Detect and correctly back off from Okta Management API rate limits across org-wide, per-user and concurrency buckets

Documented steps

1. On every Management API response read three headers: X-Rate-Limit-Limit (ceiling for the bucket that served this request), X-Rate-Limit-Remaining (requests left in the current window), X-Rate-Limit-Reset (UTC epoch seconds when the bucket resets).
2. Also read the standard Date response header and compute waitSeconds = X-Rate-Limit-Reset minus epoch(Date). Use the server Date, not the local clock, to avoid clock-skew errors in the backoff calculation.
3. Throttle proactively: queue or slow outgoing calls to a bucket once X-Rate-Limit-Remaining approaches zero, rather than waiting to be rejected.
4. On HTTP 429, stop sending to that bucket and sleep until the computed reset time before retrying only the failed request.
5. Identify which bucket applied. Org-wide limits apply per endpoint category across the whole org. Per-user limits are narrower: /api/v1/authn and /oauth2/v1/token are each capped at 4 requests per second per user. OAuth app/token limits default to 50 percent of the org bucket for the category.
6. Detect concurrency violations separately: these also return HTTP 429 but X-Rate-Limit-Limit and X-Rate-Limit-Remaining are both 0, and X-Rate-Limit-Reset is only an estimated recovery interval rather than an exact reset time. The System Log records these as core.concurrency.org.limit.violation.
7. Size client concurrency below the org ceiling: the default concurrent transaction limit is 75 for Workforce Identity and Customer Identity orgs, and 35 on the Integrator Free plan, with separate buckets for Office 365 traffic and all other/API traffic. Estimate need as Concurrency = (RPM / 60) * (avgRequestDurationMillis / 1000).
8. Back off by sleeping until the reset signaled in the headers rather than a blind fixed exponential guess; retry only the failed request.
9. Prefer the official Okta SDK's built-in rate-limit and retry configuration over hand-rolled retry logic where an SDK is available.
10. Reduce call volume structurally: request limit=200 pages instead of many small pages, use event hooks instead of polling, and cache read-heavy single-resource GETs.
11. Monitor the System Log for rate-limit and concurrency violation events so you see pressure building before production traffic starts failing.
12. Official docs consulted: https://developer.okta.com/docs/reference/rate-limits/ | https://developer.okta.com/docs/reference/rl2-monitor/ | https://developer.okta.com/docs/reference/rl2-concurrency/ | https://developer.okta.com/docs/reference/rl-additional-limits/