API rate limits
API endpoint throttling limits protect the Okta service (in
Production and Preview tenants) from load spikes or service interruptions caused by
submitted requests (whether unintentional or as a Denial of Service attack). This
strategy has been adopted across the industry in many SaaS applications and platforms
to maintain consistent service levels for customers. Requests that hit the rate limits
return a 429 Too Many Requests HTTP status code.
Public applications are aggressively rate-limited to prevent abuse and require primary authentication to be successfully completed before releasing any metadata about a user. For more information, see Okta Authentication API. For detailed information about default Okta API rate limits, including working with headers that report the limit in each API response, see Rate Limits.
Other default rate limits by endpoint are available in the following table. If an endpoint isn't in this list, you can view it in the Admin Console in . See APIs table. Okta may raise or lower the limits without notice in the process of maintaining the service.
|
Rate Limited URI |
Requests per minute |
|---|---|
|
/app/{app}/{key}/sso/saml |
750 |
|
/app/office365/{key}/sso/wsfed/active |
2,000 |
|
/app/office365/{key}/sso/wsfed/passive |
250 |
|
/app/template_saml_2_0/{key}/sso/saml |
2,500 |
|
/login/do-login |
200 |
|
/login/login.htm |
850 |
|
/login/sso_iwa_auth |
500 |
| /login/agentlessDSSO | 1000 |
| /api/plugin/{protocol version}/form-cred/{app user IDs}/{form site option} | 650 |
| /api/plugin/{protocol version}/sites | 150 |
| /bc/fileStoreRecord | 500 |
| /bc/globalFileStoreRecord | 500 |
Concurrent rate limits
To protect the service for all customers, Okta enforces concurrent rate limits. These limits are distinct from the org-wide, per minute API rate limits.
For concurrent rate limits, traffic is measured in three different areas: agent traffic, Microsoft Office 365 traffic, and all other traffic, including API requests. Counts in one area aren't included in counts for the other two areas.
- For agent traffic, Okta measured each org’s traffic and set the limit at above the highest usage in the last four weeks.
- For Microsoft Office 365 traffic, the limit is 75 concurrent transactions per org.
- For all other traffic including API requests, the limit is 75 concurrent transactions per org.
The first request to exceed the concurrent limit returns an HTTP 429 error, and the first error every sixty seconds is written to the log. Reporting concurrent rate limits once a minute keeps log volume manageable.
Default rate limits
API endpoint throttling limits have been created to protect the Okta service (in Production and Preview tenants) from load spikes or service interruptions caused by submitted requests, whether unintentional or as a Denial of Service attack. This strategy has been adopted across the industry in many SaaS applications and platforms to maintain consistent service levels for customers. Requests that hit the rate limits return a 429 Too Many Requests HTTP status code.
Public applications are aggressively rate-limited to prevent abuse and require primary authentication to be successfully completed before releasing any metadata about a user.
End-user rate limit
Okta limits the number of requests from the Okta user interface to 40 requests per user per 10 seconds per endpoint. This rate limit protects users from each other, and from other API requests in the system.
If a user is able to exceed this limit, they're locked out until the rate limit passes, and a message is written to the user interface and the System Log.
API rate limits by token
By default, Okta API tokens created through the Admin Console () are configured to have 50 percent of an API endpoint's rate limit. This configuration avoids one API token exceeding the endpoint's rate limit violation in an org with multiple API tokens. You can change the default API token capacity values in the Admin Console. See Set token rate limits.
Reducing the rate limit across all APIs for each API token prevents one API token from consuming the entire endpoint rate, assists with investigating rate-limit violations, and prevents future violations.
Burst rate limits
Burst rate limits provide your org with additional requests above an endpoint limit. This burst limit avoids suspension of end users based on unplanned traffic. See Burst rate limits.
Requesting exceptions
While endpoint throttling is enforced uniformly for all Okta customers, there are occasionally scenarios where a customer request for a temporary rate limit increase can be accommodated. An example would be an initial deployment scenario where a large number of users and groups are being imported to Okta. In such a scenario, the customer can seek to make arrangements for a temporary exception.
Requests must be received 10 business days before the time frame during which an increase is required. To request an exception, open a case with Okta Support and provide the following details:
- Org Name
- Provide the entire URL
- ex. https://cloudcompany.okta.com or https://unicorn.oktapreview.com
- Endpoints and Rates
- Which URI's need to have their limits increased
- How much of an increase is required?
- Start date and time
- End date and time
- Business Justification
Provide details on your organizations requirements that drive the request.
Okta reserves the right to rate limit other functionality to prevent abuse, spam, denial-of-service attacks, or other security issues. Where possible Okta offers a descriptive error code.