You are here: Okta-docs > Security > API


Use the API page to manage and create all Okta API tokens, and to add Origin URLs.


API tokens are used to authenticate requests to the Okta API just like HTTP cookies authenticate requests to the Okta Application with your browser. An API token is issued for a specific user and all requests with the token act on behalf of the user. API tokens are secrets and should be treated like passwords.

API tokens are valid for 30 days and automatically renew every time they are used with an API request. When a token has been inactive for more than 30 days it is revoked and cannot be used again. Tokens are also only valid if the user who created the token is also active. Tokens issued by deactivated usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. are rejected. If the user account is reactivated, the API token is accepted with no other action required.

Okta Agents are also issued API tokens during installation which they use to access your Okta organization. While these tokens are similar to the standard API token, they are usually managed by Okta.

Use the API Token page to manage all Okta API tokens. AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. tokens are usually managed when you activate, deactivate, or reactivate an agent.

Agent tokens are displayed on this page for your review, and to highlight any security issues that might arise with them. Most agents use a token. The token setup is usually handled automatically when you activate or reactivate an agent. This list of tokens is a comprehensive report of all Okta token usage for your organization.

There are five actions available to manage tokens.

Trusted Origins tab

All cross-origin web requests and redirects from Okta to your organization’s websites must be explicitly whitelisted. Use the Trusted Origins tab to grant access to websites that you control and trust to access your Okta orgAn abbreviation of organization, but can also be thought of as a company. A company that uses Okta as their SSO portal is generally referred to as an org. As an administrator, you decide how Okta should be displayed and/or integrated with your org. through the Okta API. An Origin is a security-based concept that combines the URI scheme, hostname, and port number of a page.

To access the Trusted Origins page, do the following:

  1. Click Trusted Origins.
  2. Click the Add Origin button. The Add Origin screen appears.
  3. Enter the Name and Origin URL fields for the page.
  4. Choose the Origin type from the following list.
    • CORS – Cross-Origin Resource Sharing (CORS) allows JavaScript hosted on your websites to make an XMLHttpRequest to the Okta API using the Okta session cookie.
    • Redirect – Allows for browser redirection to your org's trusted websites after signing in or out.

API Rate Limiting

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. For more information, see Okta Authentication API.

Default Rate Limits

Default rate limits are listed by endpoint in the following table. Okta may raise or lower the limits without notice in the process of maintaining the service.

Rate Limited URI

Requests per minute



'/api/v1/logs 60













*10,000 is the default limit for any endpoint not listed in the table.

Verifying the Current Rate Limit

Verify the current rate limit associated with a given endpoint by using the appropriate header in API requests. For instructions, see:

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 very large number of users and groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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 prior to the timeframe during which an increase is required. To request an exception, open a case with Okta Support and provide the following details:

  1. Org Name
  2. Endpoints and Rates
    • Which URI's need to have their limits increased
    • How much of an increase is required?
  3. Start date and time
  4. End date and time
  5. Business Justification
    • Please 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 will offer a descriptive error code.