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). Throttling limits protect the service 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 apps 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. 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.
Rate limit increase requests
Workforce Identity Cloud and Customer Identity Cloud customers can request a rate limit increase by opening a support case. After the request is submitted, Okta support teams review each request thoroughly and either grant or deny the request. You must submit requests at least 15 business days before the rate limit increase is needed. Some requests can take longer to review. Okta recommends submitting requests as far in advance as possible.
Each request is evaluated independently. Approval of a previous request doesn't guarantee future approval. Okta assesses the impact of each request on system performance and available capacity at the time of submission.
Okta is less likely to approve rate limit increases on endpoints for administrative actions like creating or modifying users, groups, or apps, due to the additional complexity involved.
If you make a request for endpoints that are covered by Dynamic Scale or Workforce Multipliers, Okta may deny the request and require that you consult with your account team to explore purchasing Dynamic Scale or increasing your Workforce Multipliers. Typically, this would occur if one of the following situations occur:
-
You request a temporary rate limit increase multiple times in a calendar year.
-
You request a rate limit increase that's greater than or equal to five times the default rate limit.
-
You request a permanent rate limit increase.
Otherwise, fill out the following information. Failure to provide accurate information may result in delays or denial of your request.
Organization information:
-
Org name
-
Org URL
Request details:
-
Start time
-
End time (if it's a permanent request, set the value as Permanent)
-
Business justification
-
Exact API URI
-
Operation: read or write
-
Target rate limit
-
Rationale for target rate limit
-
Additional information (if applicable)
-
Any additional context or evidence to justify the rate limit increase request
-
For example, auth flows, process flows, volume of requests, or performance test results
-
Okta may raise or lower the limits without notice in the process of maintaining the service. Okta reserves the right to put rate limits on other functionality to prevent abuse, spam, denial-of-service attacks, or other security issues.