Everything an AI agent can do with the Okta API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints33
API versionv1
Last updated23 June 2026
Orientation

How the Okta API works.

The Okta API is how an app or AI agent works with an Okta org: listing and creating users, adding people to groups, assigning applications, reading the system log, and deactivating an account when someone leaves. Access is granted through an API token or an OAuth access token carrying named scopes, each scope set to read or manage, and an agent is limited to the areas those scopes cover. Okta can also push events to an event hook when something happens, like a user being created or a session starting.

33Endpoints
9Capability groups
13Read
20Write
11Permissions
Authentication
Every call needs a token in the Authorization header against the org base URL https://{yourOktaDomain}. Two schemes exist. An OAuth 2.0 access token, requested by a service app using Private Key JWT and sent as 'Authorization: Bearer ', carries only the scopes it was granted. An SSWS API token, sent as 'Authorization: SSWS ', is not scoped and inherits the full permissions of the admin who created it. Okta recommends OAuth 2.0 with scopes over API tokens, because an API token has access to everything the admin can reach.
Permissions
OAuth access uses named scopes in the form okta.., where the level is read or manage. A read scope can only view, such as okta.users.read, okta.groups.read, okta.apps.read, okta.policies.read, okta.sessions.read, or okta.logs.read. A manage scope can read, create, update, and delete, such as okta.users.manage, okta.groups.manage, okta.apps.manage, okta.policies.manage, or okta.sessions.manage. There is no separate create or delete scope; manage covers all of those. An SSWS API token ignores scopes entirely and is bounded only by the creating admin's role.
Versioning
The Management API has one path version, v1, and is not versioned by date. It is continuously updated, so new fields and endpoints appear without a new version string, and behavioral changes are announced through the monthly API release notes for the Identity Engine and Classic Engine rather than a header an integration pins. Breaking changes are flagged in those release notes ahead of time.
Data model
The API is resource-oriented JSON over HTTPS at the org base URL https://{yourOktaDomain}. Core resources live under /api/v1, including /api/v1/users, /api/v1/groups, /api/v1/apps, /api/v1/policies, /api/v1/sessions, and /api/v1/logs. Lifecycle changes, such as activating, deactivating, suspending, or unlocking a user, are their own POST endpoints under a /lifecycle path rather than a field on the object. Event hooks complement the API by pushing events out when they occur.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Okta determines what it can reach. There are several routes, each governed by the token behind it and the scopes that token carries.

Ways to connect

Management API (REST)

The Management API answers at the org base URL https://{yourOktaDomain} under /api/v1. It is resource-oriented JSON over HTTPS and is reached with either an OAuth 2.0 access token or an SSWS API token.

Best forConnecting an app or AI agent to Okta.
Governed byThe token and the scopes it carries.
Docs ↗

MCP server (Model Context Protocol)

Okta's first-party MCP server connects an AI agent to an Okta org through the Model Context Protocol. It is self-hosted from the official okta-mcp-server project, authenticates with a service app using the Device Authorization Grant or Private Key JWT, and dynamically exposes only the tools its granted scopes allow. Destructive actions, like deletes and deactivations, prompt for confirmation.

Best forConnecting an app or AI agent to Okta.
Governed byThe scopes granted to the MCP server's Okta admin app.
Docs ↗

Event hooks

Event hooks deliver chosen event types to a registered HTTPS URL with an outbound POST when each event fires. Okta confirms the endpoint once through a verification challenge that must be echoed back, then delivers events asynchronously with a three-second timeout and at most one retry.

Best forConnecting an app or AI agent to Okta.
Governed byThe token and the scopes it carries.
Docs ↗
Authentication

OAuth 2.0 for Okta (service app)

A service app authenticates with Private Key JWT and receives an access token that carries only the scopes it was granted, in the form okta... This is the least-privilege choice and the one Okta recommends for connecting to the Management API.

TokenOAuth 2.0 access token (Bearer)
Best forLeast-privilege machine-to-machine access
Docs ↗

SSWS API token

An API token is sent as 'Authorization: SSWS '. It is not scoped and inherits the full permissions of the admin account that created it, so it can reach everything that admin can. It is simpler to set up but gives no per-scope control.

TokenSSWS API token
Best forQuick setup where scoping is not required
Docs ↗
Capability map

What an AI agent can do in Okta.

The Okta Management API is split into areas an agent can act on, such as users, groups, applications, sessions, policies, and the system log. Each area has its own methods and its own scopes, and some grant access to far more than others.

Endpoint reference

Every Okta API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Users

List, read, create, update, replace, and delete users in the org.6

An SSWS API token reaches this with the creating admin's permissions and ignores scopes.

Acts onuser
Permission (capability)okta.users.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

There is no separate create scope; okta.users.manage covers create, update, and delete.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventuser.lifecycle.create
Rate limitStandard limits apply

Returns the user's profile, status, and credential metadata.

Acts onuser
Permission (capability)okta.users.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A POST applies a partial update; the PUT replace endpoint overwrites the whole profile.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventuser.account.update_profile
Rate limitStandard limits apply

Unset profile fields are cleared, unlike the partial POST update.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Deletion is permanent and removes the account from the org.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

User lifecycle

Activate, deactivate, reactivate, suspend, unsuspend, and unlock a user account.4

Lifecycle transitions are their own endpoints, not a field on the user object.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Deactivation is a prerequisite for deleting the user.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventuser.lifecycle.deactivate
Rate limitStandard limits apply

Suspend is reversible with unsuspend; the account and its data remain.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the user to active status without resetting their password.

Acts onuser
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Groups

List, read, create, replace, and delete groups, list members, and add or remove a user.6

Covers Okta groups, app groups, and rule-built groups.

Acts ongroup
Permission (capability)okta.groups.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Creates a group of type OKTA_GROUP that members can be assigned to.

Acts ongroup
Permission (capability)okta.groups.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the group profile and type.

Acts ongroup
Permission (capability)okta.groups.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the users currently in the group.

Acts ongroup
Permission (capability)okta.groups.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Adds membership; the user gains anything that group grants, such as app access.

Acts ongroup
Permission (capability)okta.groups.manage
VersionAvailable since the API’s base version
Webhook eventgroup.user_membership.add
Rate limitStandard limits apply

Removes membership and anything that group granted the user.

Acts ongroup
Permission (capability)okta.groups.manage
VersionAvailable since the API’s base version
Webhook eventgroup.user_membership.remove
Rate limitStandard limits apply

Applications

List, read, create, replace, delete, activate, and deactivate the applications connected to the org.3

Returns each app's status, sign-on mode, and settings.

Acts onapplication
Permission (capability)okta.apps.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Adds a new app that users and groups can then be assigned to.

Acts onapplication
Permission (capability)okta.apps.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Activation and deactivation are their own lifecycle endpoints.

Acts onapplication
Permission (capability)okta.apps.manage
VersionAvailable since the API’s base version
Webhook eventapplication.lifecycle.activate
Rate limitStandard limits apply

Application assignments

List, assign, read, update, and unassign the users granted access to an application.3

Shows who can reach the app and their app-specific profile.

Acts onapplication user
Permission (capability)okta.apps.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Direct assignment; group assignment grants access through group membership instead.

Acts onapplication user
Permission (capability)okta.apps.manage
VersionAvailable since the API’s base version
Webhook eventapplication.user_membership.add
Rate limitStandard limits apply

Removes direct access; group-based access ends only when the group assignment is removed.

Acts onapplication user
Permission (capability)okta.apps.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Sessions

Read, refresh, and revoke a user's Okta session.3

Returns the session status, the user, and when it expires.

Acts onsession
Permission (capability)okta.sessions.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Extends the session up to the policy maximum, it does not reset the absolute lifetime.

Acts onsession
Permission (capability)okta.sessions.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Ends the session immediately; the user must sign in again.

Acts onsession
Permission (capability)okta.sessions.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Policies

List, read, create, replace, delete, activate, and deactivate the policies that govern sign-in and security.4

A type query parameter selects the policy category to list.

Acts onpolicy
Permission (capability)okta.policies.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Policies set org-wide rules, so this changes how everyone signs in.

Acts onpolicy
Permission (capability)okta.policies.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns the policy settings and its conditions.

Acts onpolicy
Permission (capability)okta.policies.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Rules decide which conditions trigger the policy and what action it takes.

Acts onpolicy rule
Permission (capability)okta.policies.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Factors (MFA)

List, enroll, read, and unenroll the multi-factor authentication factors on a user.3

Factors are governed by the user scopes, not a separate factor scope.

Acts onfactor
Permission (capability)okta.users.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Some factor types need a follow-up activate call to finish enrollment.

Acts onfactor
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Removing the last factor can force re-enrollment at next sign-in, per policy.

Acts onfactor
Permission (capability)okta.users.manage
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

System log

Read the system log of events across the org for audit and monitoring.1

The log is read-only and is the source catalog for event hook event types.

Acts onlog event
Permission (capability)okta.logs.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Okta can notify an app or AI agent when something happens in an org, instead of the app repeatedly asking. Okta sends the event to an event hook URL that has been registered for the chosen event types, after a one-time verification handshake.

EventWhat it signalsTriggered by
user.lifecycle.createFires when a new user is created in the org./api/v1/users
user.lifecycle.deactivateFires when a user is deactivated./api/v1/users/{id}/lifecycle/deactivate
user.account.update_profileFires when a user's profile is updated./api/v1/users/{id}
group.user_membership.addFires when a user is added to a group./api/v1/groups/{groupId}/users/{userId}
group.user_membership.removeFires when a user is removed from a group./api/v1/groups/{groupId}/users/{userId}
application.lifecycle.activateFires when an application is activated./api/v1/apps/{appId}/lifecycle/activate
application.user_membership.addFires when a user is assigned to an application./api/v1/apps/{appId}/users
user.session.startFires when a user session starts, after a successful sign-in.In-app only
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Okta limits how fast an app or AI agent can call, through per-org and per-endpoint request quotas plus a separate concurrent limit on how many requests can be in flight at once. The ceilings depend on the org plan and add-ons.

Request rate

Okta meters requests with rate-limit buckets, where a bucket is a set of endpoints that share a quota over a time window. The most general bucket is the whole org, and finer buckets apply per endpoint and per client app, so heavy use of one endpoint does not drain the budget for others. A separate concurrent rate limit caps how many requests can be in flight at the same time, independent of the per-minute quota. The exact ceilings depend on the org plan, the HTTP method, the licenses bought, and add-ons such as DynamicScale, so they are not a single fixed number. Every response carries X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset so a client can see its remaining budget and when the window resets, and exceeding a limit returns HTTP 429 with errorCode E0000047.

Pagination

List endpoints use cursor-based pagination through the limit query parameter and a Link response header. The header carries a rel="next" URL with the cursor for the following page, which should be followed rather than built by hand, and pagination ends when no rel="next" link is present. The limit parameter sets the page size, with a per-endpoint maximum, and the System Log uses the same Link-header model.

Request size

Requests and responses are JSON. Page sizes are capped per endpoint through the limit parameter, for example up to 200 users or 1000 System Log events per page, and some search and filter parameters have their own length limits. There is no single documented payload size limit across the whole API.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
400E0000001API validation failed. The request was reachable but a field is missing or invalid, with detail in the errorCauses array.Read the errorCauses array, correct the named field, and resend.
401E0000004Authentication failed. The credentials are missing, invalid, or expired.Check the token and the Authorization header, then send valid credentials.
401E0000011The API token provided is invalid.Issue a fresh API token or access token and retry with it.
403E0000006The caller does not have permission to perform the requested action, because the token lacks the required scope or the admin role lacks the right.Grant the missing scope or role, then retry.
404E0000007The requested resource was not found, or the token cannot see it.Confirm the resource id and that the token has access to it.
429E0000047The API call exceeded the rate limit for too many requests in the window.Wait for the X-Rate-Limit-Reset time before retrying, and slow the request rate.
Versioning & freshness

Version history.

Okta does not version the Management API by date. There is a single path version, v1, that is continuously updated, and dated changes ship through the API release notes rather than a new version string.

Version history

What changed, and when

Latest versionv1
v1Current version
Continuously updated, tracked through release notes

The Okta Management API uses a single path version, v1, that is continuously updated rather than versioned by date. New endpoints and fields are added over time, and notable changes ship through the monthly API release notes for the Identity Engine and Classic Engine. The entries below are recent dated highlights from those release notes.

What changed
  • 2026: Identity Claims Sourcing Policy added, letting federated users re-authenticate with their most recent active SSO identity provider
  • 2026: Okta Managed User Accounts API made available for Okta Privileged Access orgs, to monitor and control SaaS service accounts
  • 2026: Policies API extended to control automatic enrollment of email as an authenticator and email-based recovery
2025 release notes
Identity Engine API updates through 2025

Through 2025 the Identity Engine API gained new management capabilities, delivered as additive changes to v1 and announced in the API release notes rather than as a new version string.

What changed
  • Ongoing additions to user, group, application, and policy management endpoints
  • Refinements to OAuth 2.0 scopes and service-app authentication for the Management API

An integration tracks changes through the release notes rather than pinning a version.

Okta API release notes ↗
Questions

Okta API, answered.

OAuth 2.0 scopes or an SSWS API token, which should I use?+
OAuth 2.0 with scopes is the better default and what Okta recommends. A service app authenticates with Private Key JWT and receives an access token that carries only the scopes it was granted, such as okta.users.read on its own, so it can be limited to exactly what it needs. An SSWS API token is not scoped at all and inherits every permission of the admin account that created it, which means it can reach anything that admin can. Scoped OAuth tokens give least-privilege access; API tokens do not.
What does a scope like okta.users.manage actually allow?+
Okta scopes follow the pattern okta.., where the level is either read or manage. A read scope such as okta.users.read can only view, so it covers listing and retrieving users. A manage scope such as okta.users.manage is broader: it can read, create, update, and delete, and it also covers lifecycle actions like activating, deactivating, suspending, and unlocking a user. There is no separate okta.users.create or okta.users.delete scope, so granting manage grants all of those at once.
How do I receive events instead of polling?+
Okta event hooks deliver events without polling. An HTTPS URL is registered, a set of event types is chosen, such as user.lifecycle.create or group.user_membership.add, and Okta confirms the endpoint once through a verification challenge it expects echoed back. After that, Okta sends an HTTPS POST with the event data when each event fires. The event types available are a subset of what the System Log records. Event hooks report that something happened; inline hooks, a separate feature, can pause a flow and change its outcome.
What are the rate limits?+
Okta meters requests in buckets that share a quota over a time window, scoped to the whole org and to individual endpoints, plus a separate concurrent limit on how many requests can run at once. The numbers depend on the org plan, the HTTP method, and add-ons such as DynamicScale, so there is no single figure. Each response includes X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset, and going over returns HTTP 429 with errorCode E0000047, after which a client should wait for the reset time before retrying.
How does the API report errors?+
Errors come back as a JSON object with errorCode, errorSummary, errorLink, errorId, and an optional errorCauses array. The errorCode is a stable identifier in the form E0000nnn, such as E0000004 for failed authentication, E0000006 for a missing permission, E0000007 for a resource not found, and E0000047 for a rate limit hit. The errorSummary is a human-readable description, and the errorId is a unique value to quote to Okta Support when investigating a specific failure.
Does Okta version its API?+
The Management API has a single path version, v1, and is not versioned by date or by a header an integration pins. It is continuously updated, so new endpoints and fields appear over time, and notable or breaking changes are announced through Okta's monthly API release notes for the Identity Engine and Classic Engine. The practical way to track changes is to follow those release notes rather than to pin a version.
Related

More security API guides for agents

What is Bollard AI?

Control what every AI agent can do in Okta.

Bollard AI sits between a team's AI agents and Okta. Grant each agent exactly the access it needs, read or manage, area by area, and every call is checked and logged.

  • Set read, manage, or no access per agent, never a shared Okta API token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Okta
Joiner-Mover-Leaver Agent
Read users and groups ResourceOffReadFull use
Assign users to groups ActionOffReadFull use
Deactivate or delete users ActionOffReadFull use
Change policies ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Okta