Okta

Activates a scheduled agent pool update

Activates an API Service Integration instance Secret by `secretId`

Activates an inactive application

Activates an authenticator by `authenticatorId`

Activates a method for an authenticator identified by `authenticatorId` and `methodType`

Activates an authorization server

Activates an authorization server policy

Activates an authorization server policy rule

Activates a behavior detection rule

Activates a custom telephony provider by its ID. You must activate a provider before it can be used.

Activates the default provisioning connection for an app

Activates a device by setting its status to `ACTIVE` by `deviceId`. Activated devices are used to create and delete device user links.

Activates a device integration and populates the related configurations by `deviceIntegrationId`

Activates the event hook that matches the provided `id`

Activates a factor. Some factors (`call`, `email`, `push`, `sms`, `token:software:totp`, `u2f`, and `webauthn`) require activation to complete the enrollment process. Okta enforces a rate limit of five activation attempts within five minutes. After a user exceeds the rate limit, Okta returns an error message. > **Notes:** > * If the user exceeds their SMS, call, or email factor activation rate limit, then an [OTP resend request](./#tag/UserFactor/operation/resendEnrollFactor) isn't allowed for the same factor. > * You can't use the Factors API to activate Okta FastPass (`signed_nonce`) for a user. See [Configure Okta FastPass](https://help.okta.com/okta_help.htm?type=oie&id=ext-fp-configure).

Activates a specific group rule by ID from your org

Activates an inactive identity provider (IdP)

Activates the inline hook by `inlineHookId`

Activates a log stream by `logStreamId`

Activates a Network Zone by `zoneId`

Activates an OAuth 2.0 client JSON Web Key by `keyId` > **Note:** You can have only one active encryption key at any given time for an app. When you activate an inactive key, the current active key is automatically deactivated.

Activates an OAuth 2.0 client secret by `secretId`

Activates a custom authorization server public JSON web key by key `id`. > **Note:** You can have only one active key at any given time for the authorization server. When you activate an inactive key, Okta automatically deactivates the current active key.

Activates a policy

Activates a policy rule identified by `policyId` and `ruleId`

Activates a preregistered WebAuthn factor. As part of this operation, Okta first decrypts and verifies the factor PIN and enrollment data sent by the fulfillment provider.

Activates a realm assignment

Activates a security events provider instance by setting its status to `ACTIVE`. This operation resumes the flow of events from the security events provider to Okta.

Activates a trusted origin. Sets the `status` to `ACTIVE`.

Activates a user. Perform this operation only on users with a `STAGED` or `DEPROVISIONED` status. Activation of a user is an asynchronous operation. * The user has the `transitioningToStatus` property with an `ACTIVE` value during activation. This indicates that the user hasn't completed the asynchronous operation. * The user has an `ACTIVE` status when the activation process completes. Users who don't have a password must complete the welcome flow by visiting the activation link to complete the transition to `ACTIVE` status. > **Note:** If you want to send a branded user activation email, change the subdomain of your request to the custom domain that's associated with the brand. > For example, change `subdomain.okta.com` to `custom.domain.one`. See [Multibrand and custom domains](https://developer.okta.com/docs/concepts/brands/#multibrand-and-custom-domains). > **Note:** If you have optional password enabled, visiting the activation link is optional for users who aren't required to enroll a password. > See [Create user with optional password](/openapi/okta-management/management/user/create-user-with-optional-password#user/Create-user-with-optional-password). > **Legal disclaimer** > After a user is added to the Okta directory, they receive an activation email. As part of signing up for this service, > you agreed not to use Okta's service/product to spam and/or send unsolicited messages. > Please refrain from adding unrelated accounts to the directory as Okta is not responsible for, and disclaims any and all > liability associated with, the activation email's content. You, and you alone, bear responsibility for the emails sent to any recipients.

Adds a new group with the `OKTA_GROUP` type to your org. > **Note:** App import operations are responsible for syncing groups with `APP_GROUP` type such as Active Directory groups. See [About groups](https://help.okta.com/okta_help.htm?id=Directory_Groups) in the help documentation.

Adds a new JSON Web Key to the client`s JSON Web Keys. > **Note:** This API doesn't allow you to add a key if the existing key doesn't have a `kid`. This is also consistent with how the [Dynamic Client Registration](/openapi/okta-oauth/oauth/client) or [Applications](/openapi/okta-management/management/tags/application) APIs behave, as they don't allow the creation of multiple keys without `kids`. Use the [Replace an Application](/openapi/okta-management/management/application/replaceapplication) or the [Replace a Client Application](/openapi/okta-oauth/oauth/client/replaceclient) operation to update the JWKS or [Delete an OAuth 2.0 Client JSON Web Key](/openapi/okta-management/management/applicationssopublickeys/deletejwk) and re-add the key with a `kid`.

Adds more members to a role resource set binding

Adds a new JSON Web Key to the custom authorization server`s JSON web keys. > **Note:** This API doesn't allow you to add a key if the existing key doesn't have a `kid`. Use the [Replace an Authorization Server](/openapi/okta-management/management/authorizationserver/replaceauthorizationserver) operation to update the JWKS or [Delete a Custom Authorization Server Public JSON Web Key](/openapi/okta-management/management/oauth2resourceservercredentialskeys/deleteoauth2resourceserverjsonwebkey) and re-add the key with a `kid`. > **Note:** This API doesn't allow you to add a key with an ACTIVE status. You need to add an INACTIVE key first, and then ACTIVATE the key.

Adds a resource with conditions for a resource set

Adds more resources to a resource set

Assigns all apps as target to an `APP_ADMIN` role

Assigns an app instance target to an `APP_ADMIN` role assignment to a group. When you assign the first OIN app or app instance target, you reduce the scope of the role assignment. The role no longer applies to all app targets, but applies only to the specified target. > **Note:** You can target a mixture of both OIN app and app instance targets, but you can't assign permissions to manage all instances of an OIN app and then assign a subset of permissions to the same app. > For example, you can't specify that an admin has access to manage all instances of the Salesforce app and then also manage specific configurations of the Salesforce app.

Assigns an app instance target to an `APP_ADMIN` role assignment to an admin user. When you assign the first OIN app or app instance target, you reduce the scope of the role assignment. The role no longer applies to all app targets, but applies only to the specified target. > **Note:** You can target a mixture of both OIN app and app instance targets, but can't assign permissions to manage all instances of an OIN app and then assign a subset of permission to the same OIN app. > For example, you can't specify that an admin has access to manage all instances of the Salesforce app and then also manage specific configurations of the Salesforce app.

Assigns an app instance target to an `APP_ADMIN` role assignment to a client. When you assign the first OIN app or app instance target, you reduce the scope of the role assignment. The role no longer applies to all app targets, but applies only to the specified target. > **Note:** You can target a mixture of both OIN app and app instance targets, but you can't assign permissions to manage all instances of an OIN app and then assign a subset of permissions to the same app. For example, you can't specify that an admin has access to manage all instances of the Salesforce app and then also manage only specific configurations of the Salesforce app.

Assigns an OIN app target for an `APP_ADMIN` role assignment to a client. When you assign an app target from the OIN catalog, you reduce the scope of the role assignment. The role assignment applies to only app instances that are included in the specified OIN app target. An assigned OIN app target overrides any existing app instance targets. For example, if a user is assigned to administer a specific Facebook instance, a successful request to add an OIN app target with `facebook` for `appName` makes that user the administrator for all Facebook instances.

Assigns an OIN app target to an `APP_ADMIN` role assignment to a group. When you assign the first OIN app target, you reduce the scope of the role assignment. The role no longer applies to all app targets, but applies only to the specified target. An OIN app target that's assigned to the role overrides any existing instance targets of the OIN app. For example, if a user is assigned to administer a specific Facebook instance, a successful request to add an OIN app with `facebook` for `appName` makes that user the administrator for all Facebook instances.

Assigns an OIN app target for an `APP_ADMIN` role assignment to an admin user. When you assign the first app target, you reduce the scope of the role assignment. The role no longer applies to all app targets, but applies only to the specified target. Assigning an OIN app target overrides any existing app instance targets of the OIN app. For example, if a user was assigned to administer a specific Facebook instance, a successful request to add an OIN app target with `facebook` for `appName` makes that user the admin for all Facebook instances.

Assigns an app to an [app sign-in policy](/openapi/okta-management/management/tags/policy/), identified by `policyId`. If the app was previously assigned to another policy, this operation replaces that assignment with the updated policy identified by `policyId`. > **Note:** When you [merge duplicate app sign-in policies](https://help.okta.com/okta_help.htm?type=oie&id=ext-merge-auth-policies), the policy and mapping CRUD operations may be unavailable during the consolidation. When the consolidation is complete, you receive an email with merged results.

Assigns the [Super Admin role](https://help.okta.com/okta_help.htm?type=oie&id=ext_superadmin) as the default role for new public client apps

Assigns the fulfillment error status to a WebAuthn preregistration factor for a user. The `/mark-error` path indicates that the specific `FULFILLMENT_ERRORED` AuthFactor status is set on the enrollment.

Assigns a group owner

Assigns a group target to a [`USER_ADMIN`](/openapi/okta-management/guides/roles/#standard-roles), `HELP_DESK_ADMIN`, or `GROUP_MEMBERSHIP_ADMIN` role assignment to a client app. When you assign the first group target, you reduce the scope of the role assignment. The role no longer applies to all targets, but applies only to the specified target.

Assigns a group target to a [`USER_ADMIN`](/openapi/okta-management/guides/roles/#standard-roles), `HELP_DESK_ADMIN`, or `GROUP_MEMBERSHIP_ADMIN` role assignment to a group. When you assign the first group target, you reduce the scope of the role assignment. The role no longer applies to all targets but applies only to the specified target.

Assigns a group target for a `USER_ADMIN`, `HELP_DESK_ADMIN`, or `GROUP_MEMBERSHIP_ADMIN` role assignment to an admin user. When you assign the first group target, you reduce the scope of the role assignment. The role no longer applies to all targets but applies only to the specified target.

Assigns a [Group](/openapi/okta-management/management/tags/group) to an app, which in turn assigns the app to each [User](/openapi/okta-management/management/tags/user) that belongs to the group. The resulting application user [scope](/openapi/okta-management/management/applicationusers/listapplicationusers#applicationusers/listapplicationusers/t=response&c=200&path=scope) is `GROUP` since the assignment was from the group membership.

Assigns the first user as the `associated` and the second user as the `primary` for the specified relationship. If the first user is already associated with a different `primary` for this relationship, the previous link is removed. A linked object relationship can specify only one primary user for an associated user.

Assigns a [standard role](/openapi/okta-management/guides/roles/#standard-roles) to a client app. You can also assign a custom role to a client app, but the preferred method to assign a custom role to a client is to create a binding between the custom role, the resource set, and the client app. See [Create a role resource set binding](/openapi/okta-management/management/roledresourcesetbinding/createresourcesetbinding). > **Notes:** > * The request payload is different for standard and custom role assignments. > * For IAM-based standard role assignments, use the request payload for standard roles. However, the response payload for IAM-based role assignments is similar to the custom role's assignment response.

Assigns a [standard role](/openapi/okta-management/guides/roles/#standard-roles) to a group. You can also assign a custom role to a group, but the preferred method to assign a custom role to a group is to create a binding between the custom role, the resource set, and the group. See [Create a role resource set binding](/openapi/okta-management/management/roledresourcesetbinding/createresourcesetbinding). > **Notes:** > * The request payload is different for standard and custom role assignments. > * For IAM-based standard role assignments, use the request payload for standard roles. However, the response payload for IAM-based role assignments is similar to the custom role's assignment response.

Assigns a [standard role](/openapi/okta-management/guides/roles/#standard-roles) to a user. You can also assign a custom role to a user, but the preferred method to assign a custom role to a user is to create a binding between the custom role, the resource set, and the user. See [Create a role resource set binding](/openapi/okta-management/management/roledresourcesetbinding/createresourcesetbinding). > **Notes:** > * The request payload is different for standard and custom role assignments. > * For IAM-based standard role assignments, use the request payload for standard roles. However, the response payload for IAM-based role assignments is similar to the custom role's assignment response.

Assigns a user to an app for: * SSO only<br> Assignments to SSO apps typically don't include a user profile. However, if your SSO app requires a profile but doesn't have provisioning enabled, you can add profile attributes in the request body. * SSO and provisioning<br> Assignments to SSO and provisioning apps typically include credentials and an app-specific profile. Profile mappings defined for the app are applied first before applying any profile properties that are specified in the request body. > **Notes:** > * When Universal Directory is enabled, you can only specify profile properties that aren't defined in profile mappings. > * Omit mapped properties during assignment to minimize assignment errors.

Assigns a user to a group with the `OKTA_GROUP` type. > **Note:** You only can modify memberships for groups of the `OKTA_GROUP` type. App imports are responsible for managing group memberships for groups of the `APP_GROUP` type, such as Active Directory groups.

Removes emails from an email service bounce list. The emails submitted in this operation are removed from the bounce list by an asynchronous job. Any email address that passes validation is accepted for the removal process, even if there are other email addresses in the request that failed validation. > **Note:** If there are validation errors for all email addresses, a `200 OK` HTTP status is still returned.

Updates a user's password by validating the user's current password. This operation provides an option to delete all the sessions of the specified user. However, if the request is made in the context of a session owned by the specified user, that session isn't cleared. You can only perform this operation on users in `STAGED`, `ACTIVE`, `PASSWORD_EXPIRED`, or `RECOVERY` status that have a valid [password credential](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/User/#tag/User/operation/createUser!path=credentials/password&t=request). The user transitions to `ACTIVE` status when successfully invoked in `RECOVERY` status. > **Note:** The Okta account management policy doesn't support the `/users/{userId}/credentials/change_password` endpoint. See [Configure an Okta account management policy](https://developer.okta.com/docs/guides/okta-account-management-policy/main/).

Updates a user's recovery question and answer credential by validating the user's current password. You can only perform this operation on users in `STAGED`, `ACTIVE`, or `RECOVERY` status that have a valid [password credential](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/User/#tag/User/operation/createUser!path=credentials/password&t=request).

Clones an X.509 certificate for an application key credential from a source app to a target app. For step-by-step instructions to clone a credential, see [Share application key credentials for IdPs across apps](https://developer.okta.com/docs/guides/sharing-cert/main/). > **Note:** Sharing certificates isn't a recommended security practice.

Clones an X.509 certificate for an identity provider (IdP) signing key credential from a source IdP to target IdP > **Caution:** Sharing certificates isn't a recommended security practice. > **Note:** If the key is already present in the list of key credentials for the target IdP, you receive a 400 error response.

Clones an existing policy

Creates an agent pool update

Creates and authorizes an API Service Integration instance

Creates an API Service Integration instance Secret object with a new active client secret. You can create up to two Secret objects. An error is returned if you attempt to create more than two Secret objects.

Creates a new app service account for managing an app account

Creates an app instance in your Okta org. You can either create an OIN app instance or a custom app instance: * OIN app instances have prescribed `name` (key app definition) and `signOnMode` options. See the [OIN schemas](/openapi/okta-management/management/application/googleapplication) for the request body. * For custom app instances, select the [signOnMode](/openapi/okta-management/management/tags/application/other/createapplication#application/createapplication/t=request&path=&d=0/signonmode) that pertains to your app and specify the required parameters in the request body.

Creates trusted relationships between the given authorization server and other authorization servers

Creates an authenticator

Creates a Phone authenticator enrollment that's automatically activated

Creates an authorization server

Creates a policy

Creates a policy rule for the specified Custom Authorization Server and Policy

Creates a new behavior detection rule

Creates a new brand in your org

Creates a new CAPTCHA instance. Currently, an org can only configure a single CAPTCHA instance.

Creates an org (child org) that has the same features as the current requesting org (parent org). A child org inherits any new features added to the parent org, but new features added to the child org aren't propagated back to the parent org. > **Notes:** > * Some features associated with products, such as Atspoke, Workflows, and Okta Identity Governance, aren't propagated to the child org. > * Wait at least 30 seconds after a 201-Created response before you make API requests to the new child org. > * For rate limits, see [Org creation rate limits](https://developer.okta.com/docs/reference/rl-additional-limits/#org-creation-rate-limits).

Creates a Cross App Access connection

Creates a custom AAGUID for the Passkey (FIDO2 WebAuthn) authenticator

Creates your custom domain

Creates a custom telephony provider with the provided credentials

Creates a new device assurance policy

Creates a device posture check

Creates a new Email Customization <x-lifecycle class="ea"></x-lifecycle> If Custom languages for Okta Email Templates is enabled, you can create a customization for any BCP47 language in addition to the Okta-supported languages.

Creates an Email Domain in your org

Creates a custom email SMTP server configuration for your org. For more information about configuring the OAuth 2.0 authentication methods, see [Custom email providers with OAuth 2.0](https://developer.okta.com/docs/guides/custom-smtp/main/).

Creates a new event hook for your organization in `ACTIVE` status. You pass an event hook object in the JSON payload of your request. That object represents the set of required information about the event hook you're registering, including: * The URI of your external service * The [events](https://developer.okta.com/docs/reference/api/event-types/) in Okta you want to subscribe to * An optional event hook filter that can reduce the number of event hook calls. This is a self-service Early Access (EA) feature. See [Create an event hook filter](https://developer.okta.com/docs/concepts/event-hooks/#create-an-event-hook-filter). Additionally, you can specify a secret API key for Okta to pass to your external service endpoint for security verification. Note that the API key you set here is unrelated to the Okta API token you must supply when making calls to Okta APIs. Optionally, you can specify extra headers that Okta passes to your external service with each call. Your external service must use a valid HTTPS endpoint.

Creates a claim that will be included in tokens produced by federation protocols (for example: OIDC `id_tokens` or SAML Assertions)

Creates a governance bundle of entitlements for the Admin Console

Creates or links a group push mapping. **Note:** Either `targetGroupId` or `targetGroupName` must be provided, but not both. If `targetGroupId` is provided, it links to an existing group. If `targetGroupName` is provided, it creates a new group.

Creates a group rule to dynamically add users to the specified group if they match the condition. > **Note:** Group rules are created with the status set to `'INACTIVE'`.

Creates a key for use with other parts of the application, such as inline hooks > **Note:** Use the key name to access this key for inline hook operations. The total number of keys that you can create in an Okta org is limited to 50. The response is a [Key object](https://developer.okta.com/docs/reference/api/hook-keys/#key-object) that represents the key that you create. The `id` property in the response serves as the unique ID for the key, which you can specify when invoking other CRUD operations. The `keyId` provided in the response is the alias of the public key that you can use to get details of the public key data in a separate call. > **Note:** The keyId is the alias of the public key that you can use to retrieve the public key.

Creates a new identity provider (IdP) integration. #### SAML 2.0 IdP You must first add the IdP's signature certificate to the IdP key store before you can add a SAML 2.0 IdP with a `kid` credential reference. Don't use `fromURI` to automatically redirect a user to a particular app after successfully authenticating with a third-party IdP. Instead, use SAML deep links. Using `fromURI` isn't tested or supported. For more information about using deep links when signing users in using an SP-initiated flow, see [Understanding SP-Initiated Login flow](https://developer.okta.com/docs/concepts/saml/#understanding-sp-initiated-login-flow). Use SAML deep links to automatically redirect the user to an app after successfully authenticating with a third-party IdP. To use deep links, assemble these three parts into a URL: * SP ACS URL<br> For example: `https://${yourOktaDomain}/sso/saml2/:idpId` * The app to which the user is automatically redirected after successfully authenticating with the IdP <br> For example: `/app/:app-location/:appId/sso/saml` * Optionally, if the app is an outbound SAML app, you can specify the `relayState` passed to it.<br> For example: `?RelayState=:anyUrlEncodedValue` The deep link for the above three parts is:<br> `https://${yourOktaDomain}/sso/saml2/:idpId/app/:app-location/:appId/sso/saml?RelayState=:anyUrlEncodedValue` #### Smart Card X509 IdP You must first add the IdP's server certificate to the IdP key store before you can add a Smart Card `X509` IdP with a `kid` credential reference. You need to upload the whole trust chain as a single key using the [Key Store API](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/IdentityProviderKeys/#tag/IdentityProviderKeys/operation/createIdentityProviderKey). Depending on the information stored in the smart card, select the proper [template](https://developer.okta.com/docs/reference/okta-expression-language/#idp-user-profile) `idpuser.subjectAltNameEmail` or `idpuser.subjectAltNameUpn`. #### Identity verification vendors as identity providers Identity verification (IDV) vendors work like IdPs, with a few key differences. IDV vendors verify your user's identities by requiring them to submit a proof of identity. There are many ways to verify user identities. For example, a proof of identity can be a selfie to determine liveliness or it can be requiring users to submit a photo of their driver's license and matching that information with a database. There are three IDV vendors (Persona, CLEAR Verified, and Incode) with specific configuration settings and another IDV vendor type (Custom IDV) that lets you create a custom IDV vendor, using a [standardized IDV process](https://developer.okta.com/docs/guides/idv-integration/main/). You can configure each of the IDV vendors as IdPs in your org by creating an account with the vendor, and then creating an IdP integration. Control how the IDVs verify your users by using [Okta account management policy rules](https://developer.okta.com/docs/guides/okta-account-management-policy/main/). * [Persona](https://withpersona.com/) * [CLEAR Verified](https://www.clearme.com/) * [Incode](https://incode.com/) * [Custom IDV](https://help.okta.com/okta_help.htm?type=oie&id=idp-add-custom-idv-vendor)

Creates a new X.509 certificate credential in the identity provider (IdP) key store > **Note:** RSA-based certificates are supported for all IdP types. Okta currently supports EC-based certificates only for the `X509` IdP type. For EC-based certificates we support only P-256, P-384, and P-521 curves.

Creates a group in an identity source for the given identity source instance

Creates the group memberships for the given identity source group

Creates an identity source session for the given identity source instance

Creates a user in an identity source for the given identity source instance

Creates an inline hook This endpoint creates an inline hook for your org in an `ACTIVE` status. You need to pass an inline hooks object in the JSON payload of your request. That object represents the set of required information about the inline hook that you're registering, including: * The URI of your external service endpoint * The type of inline hook you're registering * The type of authentication you're registering There are two authentication options that you can configure for your inline hook: HTTP headers and OAuth 2.0 tokens. HTTP headers let you specify a secret API key that you want Okta to pass to your external service endpoint (so that your external service can check for its presence as a security measure). >**Note:** The API key that you set here is unrelated to the Okta API token you must supply when making calls to Okta APIs. You can also optionally specify extra headers that you want Okta to pass to your external service with each call. To configure HTTP header authentication, see parameters for the `config` object. OAuth 2.0 tokens provide enhanced security between Okta and your external service. You can configure these tokens for the following types&mdash;client secret and private key. >**Note:** Your external service's endpoint needs to be a valid HTTPS endpoint. The URI you specify should always begin with `https://`. The total number of inline hooks that you can create in an Okta org is limited to 50, which is a combined total for any combination of inline hook types.

Creates a mapping between the target app and an allowed app for interclient SSO using the interclient token

Creates a Linked Object definition

Creates a new log stream object

Creates a Network Zone * For an IP Network Zone, you must define either `gateways` or `proxies`. * For a Dynamic Network Zone, you must define at least one of the following: `asns`, `locations`, or `proxyType`. * For an Enhanced Dynamic Network Zone, you must define at least one of the following: `asns`, `locations`, or `ipServiceCategories`. > **Note:** To view all properties for an Enhanced Dynamic Network Zone, select `DYNAMIC_V2` from the `type` dropdown list.

Creates a custom token Claim for a custom authorization server

Creates an OAuth 2.0 client secret object with a new active client secret. You can create up to two secret objects. An error is returned if you attempt to create more than two secret objects. > **Note:** This API lets you bring your own secret. If [token_endpoint_auth_method](/openapi/okta-oauth/oauth/client/createclient#client/createclient/t=request&path=token_endpoint_auth_method) of the app is `client_secret_jwt`, then the minimum length of `client_secret` is 32 characters. If no secret is specified in the request, Okta adds a new system-generated secret.

Creates a custom token scope

Creates a new Okta managed user account for managing a Universal Directory user as a service account. You must specify an existing Okta user in your org with the `oktaUserId` request parameter.

Creates a policy. There are many types of policies that you can create. See [Policies](https://developer.okta.com/docs/concepts/policies/) for an overview of the types of policies available and links to more indepth information.

Creates a policy rule > **Note:** You can't create additional rules for the `PROFILE_ENROLLMENT`, `POST_AUTH_SESSION`, `CLIENT_UPDATE`, or <x-lifecycle class="ea"></x-lifecycle> `IDENTITY_CLAIM_SOURCING` policies.

Creates a policy or policy rule simulation. The access simulation evaluates policy and policy rules based on the existing policy rule configuration. The evaluation result simulates what the real-world authentication flow is and what policy rules have been applied or matched to the authentication flow.

Creates a new principal rate limit entity. Okta only allows one principal rate limit entity per org and principal.

Creates a new push provider. Each Push Provider must have a unique `name`.

Creates a new realm

Creates a new realm assignment

Creates a new resource set. See [Supported resources](/openapi/okta-management/guides/roles/#supported-resources). > **Note:** The maximum number of `resources` allowed in a resource set object is 1000. Resources are identified by either an Okta Resource Name (ORN) or by a REST URL format. See [Okta Resource Name](/openapi/okta-management/guides/roles/#okta-resource-name-orn).

Creates a binding for the resource set, custom role, and members (users or groups) > **Note:** If you use a custom role with permissions that don't apply to the resources in the resource set, it doesn't affect the admin role. For example, the `okta.users.userprofile.manage` permission gives the admin no privileges if it's granted to a resource set that only includes `https://{yourOktaDomain}/api/v1/groups/{targetGroupId}` resources. If you want the admin to be able to manage the users within the group, the resource set must include the corresponding `https://{yourOktaDomain}/api/v1/groups/{targetGroupId}/users` resource.

Creates a custom role

Creates a permission (specified by `permissionType`) for a custom role

Creates a security events provider instance

Creates a new custom SMS template

Creates an SSF stream for an event receiver to start receiving security events in the form of Security Event Tokens (SETs) from Okta. An SSF stream is associated with the client ID of the OAuth 2.0 access token used to create the stream. The client ID is provided by Okta for an [OAuth 2.0 app integration](https://help.okta.com/okta_help.htm?id=ext_Apps_App_Integration_Wizard-oidc). One SSF stream is allowed for each client ID, hence, one SSF stream is allowed for each app integration in Okta. You can create a maximum of 10 SSF stream configurations for one org.

Creates an auto-activated Temporary access code (TAC) authenticator enrollment

Creates a trusted origin

Creates an input for an enrollment form

Creates a new user in your Okta org with or without credentials.<br> > **Legal Disclaimer** > > After a user is added to the Okta directory, they receive an activation email. As part of signing up for this service, > you agreed not to use Okta's service/product to spam and/or send unsolicited messages. > Please refrain from adding unrelated accounts to the directory as Okta is not responsible for, and disclaims any and all > liability associated with, the activation email's content. You, and you alone, bear responsibility for the emails sent to any recipients. All responses return the created user. Activation of a user is an asynchronous operation. The system performs group reconciliation during activation and assigns the user to all apps via direct or indirect relationships (group memberships). * The user's `transitioningToStatus` property is `ACTIVE` during activation to indicate that the user hasn't completed the asynchronous operation. * The user's `status` is `ACTIVE` when the activation process is complete. The user is emailed a one-time activation token if activated without a password. > **Note:** If the user is assigned to an app that is configured for provisioning, the activation process triggers downstream provisioning to the app. It is possible for a user to sign in before these apps have been successfully provisioned for the user. > **Important:** Do not generate or send a one-time activation token when activating users with an assigned password. Users should sign in with their assigned password. For more information about the various scenarios of creating a user listed in the examples, see the [User creation scenarios](/openapi/okta-management/management/tags/user/section/user-status#section/User-creation-scenarios) section.

Creates a new user type. Okta automatically creates a `default` user type for your org. You may add up to nine additional user types. > **Note**: New user types are based on the current default schema template. Modifications to this schema do not automatically propagate to previously created user types.

Deactivates scheduled agent pool update

Deactivates an API Service Integration instance Secret by `secretId`

Deactivates an active application > **Note:** Deactivating an app triggers a full reconciliation of all users assigned to the app by groups. This reconcile process removes the app assignment for the deactivated app, and might also correct assignments that were supposed to be removed but failed previously.

Deactivates an authenticator by `authenticatorId`

Deactivates a method for an authenticator identified by `authenticatorId` and `methodType`

Deactivates an authorization server

Deactivates an authorization server policy

Deactivates an authorization server policy rule

Deactivates a behavior detection rule

Deactivates a custom telephony provider by its ID. Keep the following points in mind when you deactivate a provider: * You must deactivate a provider before deleting it. * If you have two telephony providers configured, and both are active, you can only deactivate the secondary provider. The second provider is the one that isn't set as the primary provider.

Deactivates the default provisioning connection for an app

Deactivates a device by setting its status to `DEACTIVATED` by `deviceId`. Deactivation causes a device to lose all device user links. Set the device status to `DEACTIVATED` before deleting it. > **Note:** When deactivating a Device, keep in mind the following: - Device deactivation is a destructive operation for device factors and client certificates. Device reenrollment using Okta Verify allows end users to set up new factors on the device. - Device deletion removes the device record from Okta. Reenrollment creates a new device record.

Deactivates a device integration by `deviceIntegrationId`

Deactivates the event hook that matches the provided `id`

Deactivates a specific group rule by ID from your org

Deactivates an active identity provider (IdP)

Deactivates the inline hook by `inlineHookId`

Deactivates a log stream by `logStreamId`

Deactivates a Network Zone by `zoneId`

Deactivates an OAuth 2.0 client JSON Web Key by `keyId` > **Note:** You can only deactivate signing keys. Deactivating the active encryption key isn't allowed if the client has ID token encryption enabled. You can activate another encryption key, which makes the current key inactive.

Deactivates an OAuth 2.0 client secret by `secretId`. You can't deactivate a secret if it's the only secret of the client.

Deactivates a custom authorization server public JSON web key by key `id`. > **Note:** Deactivating the active key isn't allowed if the authorization server has access token encryption enabled. You can activate another key, which makes the current key inactive.

Deactivates a policy

Deactivates a policy rule identified by `policyId` and `ruleId`

Deactivates a realm assignment

Deactivates a security events provider instance by setting its status to `INACTIVE`. This operation stops the flow of events from the security events provider to Okta.

Deactivates a trusted origin. Sets the `status` to `INACTIVE`.

Deactivates a user. Perform this operation only on users that do not have a `DEPROVISIONED` status. * The user's `transitioningToStatus` property is `DEPROVISIONED` during deactivation to indicate that the user hasn't completed the asynchronous operation. * The user's status is `DEPROVISIONED` when the deactivation process is complete. > **Important:** Deactivating a user is a **destructive** operation. The user is deprovisioned from all assigned apps, which might destroy their data such as email or files. **This action cannot be recovered!** You can also perform user deactivation asynchronously. To invoke asynchronous user deactivation, pass an HTTP header `Prefer: respond-async` with the request. > **Note:** Users with the `DEPROVISIONED` status won't have their profiles updated when running the [Update a user](/openapi/okta-management/management/user/updateuser) endpoint unless you have the **Edit Deactived User Profile Updates** option turned on in the Admin Console. See [Edit deactivated user profiles](https://help.okta.com/okta_help.htm?type=oie&id=edit-deactivated-users).

Deletes agent pool update

Deletes all customizations for an email template <x-lifecycle class="ea"></x-lifecycle> If Custom languages for Okta Email Templates is enabled, all customizations are deleted, including customizations for additional languages. If disabled, only customizations in Okta-supported languages are deleted.

Deletes an API Service Integration instance by `id`. This operation also revokes access to scopes that were previously granted to this API Service Integration instance.

Deletes an API Service Integration instance Secret by `secretId`. You can only delete an inactive Secret.

Deletes an app service account specified by ID

Deletes an inactive application

Deletes an associated Authorization Server

Deletes an existing enrollment for the specified user. The user can enroll the authenticator again.

Deletes an authorization server

Deletes a policy

Deletes a Policy Rule defined in the specified Custom Authorization Server and Policy

Deletes a Behavior Detection Rule by `behaviorId`

Deletes a binding of a role (identified by `roleIdOrLabel`) and a resource set (identified by `resourceSetIdOrLabel`)

Deletes a brand by `brandId`

Deletes a theme background image

Deletes a theme favicon. The theme will use the default Okta favicon.

Deletes a Theme logo. The theme will use the default Okta logo.

Deletes a specified CAPTCHA instance > **Note:** If your CAPTCHA instance is still associated with your org, the request fails. You must first update your Org-wide CAPTCHA settings to remove the CAPTCHA instance.

Deletes a Cross App Access connection with the specified ID

Deletes a custom AAGUID You can only delete custom AAGUIDs that an admin has created.

Deletes a custom domain by `domainId`

Deletes a custom telephony provider by its ID. Before you delete a provider, ensure that it is [deactivated](/openapi/okta-management/management/customtelephonyprovider/deactivatecustomtelephonycredential). Consider setting up another telephony provider if you still plan to use telephony in your org. See [Set up an external telephony provider](https://help.okta.com/okta_help.htm?type=oie&id=about-telephony).

Deletes the customized error page. As a result, the default error page appears in your live environment.

Deletes the customized sign-in page. As a result, the default sign-in page appears in your live environment.

Deletes (permanently) a device by `deviceId` if it has a status of `DEACTIVATED`. You can transition the device to `DEACTIVATED` status using the [Deactivate a Device](/openapi/okta-management/management/tags/device/other/deactivatedevice) endpoint. This request is destructive and deletes all of the profile data related to the device. Once deleted, device data can't be recovered. However, reenrollment creates a new device record. > **Note:** Attempts to delete a device that isn't in a `DEACTIVATED` state raise an error.

Deletes a device assurance policy by `deviceAssuranceId`. If the device assurance policy is currently being used in the org Authentication Policies, the delete will not be allowed.

Deletes a device posture check by `postureCheckId`. You can't delete the device posture check if it's used in a device assurance policy.

Deletes an Email Customization by its unique identifier <x-lifecycle class="ea"></x-lifecycle> If Custom languages for Okta Email Templates is disabled, deletion of an existing additional language customization by ID doesn't register.

Deletes an Email Domain by `emailDomainId`

Deletes the specified custom SMTP server configuration

Deletes the event hook that matches the provided `id`. After deletion, the event hook is unrecoverable. As a safety precaution, you can only delete event hooks with a status of `INACTIVE`.

Deletes a federated claim by `claimId`

Deletes an Admin Console governance bundle

Deletes a group of the `OKTA_GROUP` or `APP_GROUP` type from your org. > **Note:** You can't remove groups of type `APP_GROUP` if they are used in a group push mapping.

Deletes a group owner from a specific group

Deletes a specific group push mapping. The group push mapping must be in an `INACTIVE` state.

Deletes a specific group rule by `groupRuleId`

Deletes a key by `id`. After being deleted, the key is unrecoverable. As a safety precaution, only keys that aren't being used are eligible for deletion.

Deletes an identity provider (IdP) integration by `idpId` * All existing IdP users are unlinked with the highest order profile source taking precedence for each IdP user. * Unlinked users keep their existing authentication provider such as `FEDERATION` or `SOCIAL`.

Deletes a specific identity provider (IdP) key credential by `kid` if it isn't currently being used by an active or inactive IdP

Deletes a group in an identity source for a given identity source ID and group ID

Deletes group memberships for the specified identity source group using member external IDs

Deletes an identity source session for a given identity source ID and session Id

Deletes a user in an identity source for the given identity source instance and external ID

Deletes an inline hook by `inlineHookId`. After it's deleted, the inline hook is unrecoverable. As a safety precaution, only inline hooks with a status of `INACTIVE` are eligible for deletion.

Deletes the mapping between the target app and an allowed app

Deletes the Linked Object definition specified by either the `primary` or `associated` name. The entire definition is removed, regardless of which name that you specify.

Deletes any existing relationship between the `associated` and `primary` user. For the `associated` user, this is specified by the ID. The `primary` name specifies the relationship. The operation is successful if the relationship is deleted. The operation is also successful if the specified user isn't in the `associated` relationship for any instance of the specified `primary` and thus, no relationship is found.

Deletes a log stream object from your org by ID

Deletes a Network Zone by `zoneId` > **Notes:** > * You can't delete a Network Zone that's used by a [Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tags/policy/) or [Rule](https://developer.okta.com/docs/api/openapi/okta-management/management/tags/policy/#tag/Policy/operation/listPolicyRules). > * For Okta Identity Engine orgs, you can't delete a Network Zone with an ACTIVE `status`. <x-lifecycle class="oie"></x-lifecycle>

Deletes a custom token Claim specified by the `claimId`

Deletes an OAuth 2.0 client secret by `secretId`. You can only delete an inactive secret.

Deletes a custom authorization server public JSON web key by key `id`. You can only delete an inactive key.

Deletes a custom token scope

Deletes an Okta managed user account specified by ID. This operation removes the service account management for the Okta user, suspends the underlying Okta user account, but doesn't delete the user from Universal Directory.

Deletes the CAPTCHA settings object for your organization

Deletes a policy

Deletes the resource mapping for a policy identified by `policyId` and `mappingId`

Deletes a policy rule identified by `policyId` and `ruleId`

Deletes the preview error page. The preview error page contains unpublished changes and isn't shown in your live environment. Preview it at `${yourOktaDomain}/error/preview`.

Deletes the preview sign-in page. The preview sign-in page contains unpublished changes and isn't shown in your live environment. Preview it at `${yourOktaDomain}/login/preview`.

Deletes a push provider by `pushProviderId`. If the push provider is currently being used in the org by a custom authenticator, the delete will not be allowed.

Deletes a realm permanently. This operation can only be performed after disassociating other entities like users and identity providers from a realm.

Deletes a realm assignment

Deletes a resource set by `resourceSetIdOrLabel`

Deletes a resource (identified by `resourceId`) from a resource set

Deletes a custom role by `roleIdOrLabel`

Unassigns a role assignment (identified by `roleAssignmentId`) from a client app (identified by `clientId`)

Deletes a permission (identified by `permissionType`) from a custom role

Deletes a security events provider instance specified by `id`

Deletes an SMS template

Deletes the specified SSF stream. If the `stream_id` is not provided in the query string, the associated stream with the client ID (through the request OAuth 2.0 access token) is deleted. Otherwise, the SSF stream with the `stream_id` is deleted, if found.

Deletes a trusted origin

Deletes a UI Schema by `id`

Deletes a user permanently. This operation can only be performed on users that have a `DEPROVISIONED` status. > **Warning:** This action can't be recovered! This operation on a user that hasn't been deactivated causes that user to be deactivated. A second delete operation is required to delete the user. > **Note:** You can also perform user deletion asynchronously. To invoke asynchronous user deletion, pass an HTTP header `Prefer: respond-async` with the request. This header is also supported by user deactivation, which is performed if the delete endpoint is invoked on a user that hasn't been deactivated.

Deletes a user type permanently. > **Note**: You can't delete the default user type or a user type that is currently assigned to users.

Deletes a specific WebAuthn preregistration factor for a user

Deletes an OAuth 2.0 Client JSON Web Key by `keyId`. You can only delete an inactive key.

Enrolls a supported factor for the specified user > **Notes:** > * All responses return the enrolled factor with a status of either `PENDING_ACTIVATION` or `ACTIVE`. > * You can't use the Factors API to enroll Okta FastPass (`signed_nonce`) for a user. See [Configure Okta FastPass](https://help.okta.com/okta_help.htm?type=oie&id=ext-fp-configure). #### Additional SMS/Call factor information * **Rate limits**: Okta may return a `429 Too Many Requests` status code if you attempt to resend an SMS or a voice call challenge (OTP) within the same time window. The current [rate limit](https://developer.okta.com/docs/reference/rate-limits/) is one SMS/CALL challenge per phone number every 30 seconds. * **Existing phone numbers**: Okta may return a `400 Bad Request` status code if a user attempts to enroll with a different phone number when the user has an existing mobile phone or has an existing phone with voice call capability. A user can enroll only one mobile phone for `sms` and enroll only one voice call capable phone for `call` factor. #### Additional WebAuthn factor information * For detailed information on the WebAuthn standard, including an up-to-date list of supported browsers, see [webauthn.me](https://a0.to/webauthnme-okta-docs). * When you enroll a WebAuthn factor, the `activation` object in `_embedded` contains properties used to help the client to create a new WebAuthn credential for use with Okta. See the [WebAuthn spec for PublicKeyCredentialCreationOptions](https://www.w3.org/TR/webauthn/#dictionary-makecredentialoptions). * As of the `2026.04.0` release, the FIDO2 (WebAuthn) authenticator is now called Passkey (FIDO2 WebAuthn) and there are new settings and updates to the authenticator page layout. There have been no changes to any existing parameter names, values, or endpoint paths. For example, the `factorType` for the Passkey (FIDO2 WebAuthn) authenticator is still `webauthn`. See [Passkeys and WebAuthn](https://developer.okta.com/docs/guides/authenticators-web-authn/aspnet/main/#passkeys-and-webauthn). #### Additional Custom TOTP factor information * The enrollment process involves passing both the `factorProfileId` and `sharedSecret` properties for a token. * A factor profile represents a particular configuration of the Custom TOTP factor. It includes certain properties that match the hardware token that end users possess, such as the HMAC algorithm, passcode length, and time interval. There can be multiple Custom TOTP factor profiles per org, but users can only enroll in one Custom TOTP factor. Admins can [create Custom TOTP factor profiles](https://help.okta.com/okta_help.htm?id=ext-mfa-totp) in the Admin Console. Then, copy the `factorProfileId` from the Admin Console into the API request. * <x-lifecycle class="oie"></x-lifecycle> For Custom TOTP enrollment, Okta automaticaly enrolls a user with a `token:software:totp` factor and the `push` factor if the user isn't currently enrolled with these factors.

Enrolls a preregistered WebAuthn factor. This WebAuthn factor has a longer challenge timeout period to accommodate the fulfillment request process. As part of this operation, Okta generates elliptic curve (EC) key-pairs used to encrypt the factor PIN and enrollment data sent by the fulfillment provider.

Executes the inline hook that matches the provided `inlineHookId` by using the request body as the input. This inline hook sends the provided data through the `channel` object and returns a response if it matches the correct data contract. Otherwise it returns an error. You need to construct a JSON payload that matches the payloads that Okta would send to your external service for this inline hook type. A timeout of three seconds is enforced on all outbound requests, with one retry in the event of a timeout or an error response from the remote system. If a successful response isn't received after the request, a 400 error is returned with more information about what failed. >**Note:** This execution endpoint isn't tied to any other functionality in Okta, and you should only use it for testing purposes.

Executes a realm assignment

Expires the password. This operation transitions the user status to `PASSWORD_EXPIRED` so that the user must change their password the next time that they sign in. <br> If you have integrated Okta with your on-premises Active Directory (AD), then setting a user's password as expired in Okta also expires the password in AD. When the user tries to sign in to Okta, delegated authentication finds the password-expired status in AD, and the user is presented with the password-expired page where they can change their password. > **Note:** The Okta account management policy doesn't support the `/users/{id}/lifecycle/expire_password` endpoint. See [Configure an Okta account management policy](https://developer.okta.com/docs/guides/okta-account-management-policy/main/).

Expires the password and resets the user's password to a temporary password. This operation transitions the user status to `PASSWORD_EXPIRED` so that the user must change their password the next time that they sign in. The user's password is reset to a temporary password that's returned, and then the user's password is expired. If `revokeSessions` is included in the request with a value of `true`, the user's current outstanding sessions are revoked and require re-authentication. If you have integrated Okta with your on-premises Active Directory (AD), then setting a user's password as expired in Okta also expires the password in AD. When the user tries to sign in to Okta, delegated authentication finds the password-expired status in AD, and the user is presented with the password-expired page where they can change their password.

Extends the length of time that Okta Support can access your org by 24 hours. This means that 24 hours are added to the remaining access time. > **Note:** This resource is deprecated. Use the [Update an Okta Support case](/openapi/okta-management/management/tags/orgsettingsupport/other/updateoktasupportcase) resource to extend Okta Support access for a support case. > For the corresponding Okta Admin Console feature, see [Give access to Okta Support](https://help.okta.com/okta_help.htm?type=oie&id=settings-support-access).

Starts the forgot password flow. Generates a one-time token (OTT) that you can use to reset a user's password. The user must validate their security question's answer when visiting the reset link. Perform this operation only on users with an `ACTIVE` status and a valid [recovery question credential](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/User/#tag/User/operation/createUser!path=credentials/recovery_question&t=request). > **Note:** If you have migrated to Identity Engine, you can allow users to recover passwords with any enrolled MFA authenticator. See [Self-service account recovery](https://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/configure-sspr.htm?cshid=ext-config-sspr). If an email address is associated with multiple users, keep in mind the following to ensure a successful password recovery lookup: * Okta no longer includes deactivated users in the lookup. * The lookup searches sign-in IDs first, then primary email addresses, and then secondary email addresses. If `sendEmail` is `false`, returns a link for the user to reset their password. This operation doesn't affect the status of the user.

Resets the user's password to the specified password if the provided answer to the recovery question is correct. You must include the recovery question answer with the submission.

Generates a new X.509 certificate for an app key credential > **Note:** To update an app with the newly generated key credential, use the [Replace an Application](/openapi/okta-management/management/application/replaceapplication) request with the new [credentials.signing.kid](/openapi/okta-management/management/application/replaceapplication#application/replaceapplication/t=request&path=&d=0/credentials/signing/kid) value in the request body. You can provide just the [signing credential object](/openapi/okta-management/management/application/replaceapplication#application/replaceapplication/t=request&path=&d=0/credentials/signing) instead of the entire [application credential object](/openapi/okta-management/management/application/replaceapplication#application/replaceapplication/t=response&c=200&path=&d=0/credentials).

Generates a new key pair and returns the certificate signing request (CSR) for it. The information in a CSR is used by the Certificate Authority (CA) to verify and create your certificate. It also contains the public key that's included in your certificate. Returns CSR in `pkcs#10` format if the `Accept` media type is `application/pkcs10` or a CSR object if the `Accept` media type is `application/json`. > **Note:** The key pair isn't listed in the key credentials for the app until it's published.

Generates a new key pair and returns a certificate signing request (CSR) for it > **Note:** The private key isn't listed in the [signing key credentials for the identity provider (IdP)](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/IdentityProviderSigningKeys/#tag/IdentityProviderSigningKeys/operation/listIdentityProviderSigningKeys) until it's published.

Generates a fulfillment request by sending a WebAuthn preregistration event to start the flow. The WebAuthn preregistration integration for Okta Workflows uses a preregistration event to populate the fulfillment request.

Generates a new X.509 certificate for an identity provider (IdP) signing key credential to be used for signing assertions sent to the IdP. IdP signing keys are read-only. > **Note:** To update an IdP with the newly generated key credential, [update your IdP](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/IdentityProvider/#tag/IdentityProvider/operation/replaceIdentityProvider) using the returned key's `kid` in the [signing credential](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/IdentityProvider/#tag/IdentityProvider/operation/replaceIdentityProvider!path=protocol/0/credentials/signing/kid&t=request).

Retrieves the Okta Aerial consent grant details for your Org. Returns a 404 Not Found error if no consent has been granted.

Retrieves an agent pool update by its `updateId`

Retrieves the current state of the agent pool update instance settings

Retrieves inbound and outbound Cross App Access connections associated with an app

Retrieves the content from each of the well-known URIs for a specified brand

Retrieves an API Service Integration instance by `id`

Retrieves the metadata for an active API token by `apiTokenId`

Retrieves an app service account specified by ID

Retrieves the content of the `apple-app-site-assocation` well-known URI > **Note:** When serving this URI, Okta adds `authsrv` content to provide a seamless experience for Okta Verify. You can't modify the content in the `authsrv` object.

Retrieves an application from your Okta organization by `id`

Retrieves an app group assignment

Retrieves a specific application key credential by `kid`

Retrieves a specific user assignment for a specific app

Retrieves the default schema for an app user. The [User Types](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/UserType/) feature does not extend to apps. All users assigned to a given app use the same app user schema. Therefore, unlike the user schema operations, the app user schema operations all specify `default` and don't accept a schema ID.

Retrieves the content of the `assetlinks.json` well-known URI

Retrieves an authenticator from your Okta organization by `authenticatorId`

Retrieves a user's authenticator enrollment by `enrollmentId`

Retrieves a method identified by `methodType` of an authenticator identified by `authenticatorId`

Retrieves the Authenticator Settings for an org

Retrieves an authorization server

Retrieves an Authorization Server Key specified by the `keyId`

Retrieves a policy

Retrieves a policy rule by `ruleId`

Retrieves the org setting to automatically assign the Okta Admin Console when an admin role is assigned

Retrieves a Behavior Detection Rule by `behaviorId`

Retrieves the binding of a role (identified by `roleIdOrLabel`) for a resource set (identified by `resourceSetIdOrLabel`)

Retrieves the bot protection configuration for your org

Retrieves a brand by `brandId`

Retrieves a theme for a brand

Retrieves the customized content of a well-known URI for a specific brand and well-known URI path

Retrieves the properties of a specified CAPTCHA instance

Retrieves the org setting to assign the [Super Admin role](https://help.okta.com/okta_help.htm?type=oie&id=ext_superadmin) to new public client apps

Retrieves the Cross App Access connection with the specified ID

Retrieves a certificate signing request (CSR) for the app by `csrId`. Returns a Base64-encoded CSR in DER format if the `Accept` media type is `application/pkcs10` or a CSR object if the `Accept` media type is `application/json`.

Retrieves a specific certificate signing request (CSR) by `id`

Retrieves the ThreatInsight configuration for the org

Retrieves a custom AAGUID

Retrieves a custom domain by `domainId`

Retrieves the details of a custom telephony provider by its ID

Retrieves a Preview of an Email Customization. All variable references are populated from the current user's context. For example, `${user.profile.firstName}`. <x-lifecycle class="ea"></x-lifecycle> If Custom languages for Okta Email Templates is disabled, requests for the preview of an additional language customization by ID return a `404 Not Found` error response.

Retrieves the customized error page. The customized error page appears in your live environment.

Retrieves the customized sign-in page. The customized sign-in page appears in your live environment.

Retrieves the default error page. The default error page appears when no customized error page exists.

Retrieves the default provisioning connection for an app

Retrieves the default sign-in page. The default sign-in page appears when no customized sign-in page exists.