Okta API rate limits per authorization server: how do 429 responses interact with concurrent clients?
0 reputation · 23 May 2025, 13:13 UTC
I'm designing an integration that calls Okta APIs (Users and OAuth 2.0 token endpoints) from multiple worker processes against a single org, using one custom authorization server. My understanding from the documentation is that rate limits are enforced per endpoint and per authorization server, and that exceeding them returns HTTP 429 with a Retry-After header.
The unresolved part for me is how the budget is actually shared. If several workers hit the same endpoint concurrently, does each 429's Retry-After value reflect the org-wide bucket state, so all clients should back off for the same window? Or can one aggressive client starve the others by consuming the shared limit?
I also want to confirm whether raising the threshold via a rate limit policy on the authorization server affects only OAuth endpoints (e.g., /token, /authorize) or also management API calls like /api/v1/users, which I believe are governed by separate org-level limits.
Specific questions:
- Is the 429/Retry-After response computed against a shared per-endpoint bucket visible to all clients, or per-client?
- Do authorization-server rate limit policies apply to management API endpoints, or only to OAuth/OIDC endpoints?
- Is there a documented way to inspect current limit consumption (e.g., response headers like X-Rate-Limit-Remaining) to drive backoff decisions?