okta · sophiajose-okta · Feb 19, 2026
@@ -0,0 +1,9 @@
+   Your integration update introduced a new variable (`companyId`), and you use it in your updated redirect URL. The redirect URL changed from `https://login.myapp.io` to `https://login.myapp.io?connection={app.companyId}`. In this case, ensure that the dynamic redirect URL is also valid for existing instances where the `companyId` value isn't set.
+
+   To handle empty `companyId` values, you can define the redirect URL as:
+
+   ```bash
+   https://{String.len(app.companyId) == 0 ? 'login.myapp.io' : 'login.myapp.io?connection=' + app.companyId}
+   ```
+
+   This expression handles both scenarios where `companyId` is populated or empty.
@@ -0,0 +1,5 @@
+> **Notes:**
+> * Entitlement Management is an *Early Access* feature and it’s currently supported for integrations that manage entitlements through a SCIM server.
+> * To enable Entitlement Management feature, go to **Settings** > **Features** in the Admin Console and turn on **Enable SCIM 2.0 Entitlement Management submission**. See [Manage Early Access and Beta features](https://help.okta.com/okta_help.htm?id=ext_Manage_Early_Access_features).
+> * The **SCIM Entitlement Management properties** section only appears when you select **Entitlement Management** from the **Identity Lifecycle Management** section. This selection must be made along with the protocols that your integration supports.
+> * For instructions on configuring Entitlement Management properties, see [Configure Entitlement Management properties](/docs/guides/submit-oin-app/scim/main/#scim-2-0-entitlement-management-properties).
@@ -0,0 +1 @@
+API service
@@ -0,0 +1 @@
+API service
@@ -0,0 +1,18 @@
+1. Specify the following properties if you want to integrate to API service:
+
+    > **Note:**
+    > * The **Authentication properties** and **API service integration properties** section only displays when you select **API service** from the **Add integration capabilities** section.
+
+    | Property | Description |
+    | --- | --- |
+    | Authentication properties | |
+    | Client authentication | |
+    | Client secret | This is a confidential unique string used to prove your app’s identity during a secure exchange. Selecting this option generates a unique secret key for your app instance upon installation. Currently only client-secret authentication is supported for API service integration. |
+    | API service integration properties | |
+    | Scope | Scopes define the specific levels of access your app requires for the customer’s Okta organization. You can manually select the **scopes** from the provided list of [Okta OAuth 2.0 scopes](https://developer.okta.com/docs/api/oauth2/). You can also filter the selected and available scopes. |
+    | Tell us the reason to use scopes | Enter a quick note on how you use these scopes. |
+    | *Link to configuration guide | Specify the URL link to your customer-facing instructions on how to use API service integrations. See [Customer configuration document guidelines](/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines). |
+
+    `*` Required properties
+
+1. Click **Start testing** to save your edits and move to the testing section, where you need to enter your integration test details.
@@ -0,0 +1 @@
+For API service integration, do the testing manually.
@@ -0,0 +1,2 @@
+* [SAML - Frequently Asked Questions](/docs/concepts/saml/faqs/)
+* [Okta Developer Forum: SAML](https://devforum.okta.com/search?q=saml)
@@ -0,0 +1,10 @@
+1. On the browser redirected **Authorize integration** page, click **Install & Authorize**.
+1. Copy the client secret from the dialog and store it securely.
+    > **Note**: You must copy the client secret now. For security, it is only displayed once and cannot be retrieved later. Only a masked value will be available after you close this dialog.
+1. Click **Done**.
+1. On the **General** tab, copy the **Okta domain** and **client ID** and securely store them for your integration test.
+1. Configure your app using the Okta domain, client ID, and client secret.
+1. Perform manual testing to verify your integration.
+1. Once the testing is complete, click **Continue to submission**. The **Test integration** page appears.
+1. Ensure that the checkboxes below **Test account requirements** and **API service requirements** are in *selected* status.
+1. Click **Submit integration**.
@@ -0,0 +1,4 @@
+> **Notes:** 
+> * Universal Logout integrations are only supported for SAML 2.0 and OIDC protocols. If you want to submit a Universal Logout integration with SCIM provisioning, you must also submit an SSO integration with either SAML 2.0 or OIDC. For more information, see [Universal Logout](https://developer.okta.com/docs/guides/oin-universal-logout-overview).
+>* The **Universal logout properties** section only displays when you select **Universal Logout** along with the protocols that your integration supports from the **Select protocol** section.
+
@@ -147,11 +147,8 @@ Continue with the OIN Wizard and configure your protocol settings:
 
 #### Universal logout properties
 
-1. Specify the following properties if you want to integrate Universal Logout:
 
-    <StackSnippet snippet="universal-logout-properties"/>
-
-1. Click **Get started with testing** to save your edits and move to the testing section, where you need to enter your integration test details.
+<StackSnippet snippet="universal-logout-properties"/>
 
 #### Dynamic properties with Okta Expression Language
 
@@ -269,8 +266,8 @@ The Integrator Free Plan org has no limit on active instances. You can create as
 
 #### Generate an instance for <StackSnippet snippet="protocol-name" inline/>
 
-> **Note:** The steps in this section are for generating one instance to test the **<StackSnippet snippet="protocol-name" inline/>** protocol. <br>
-> If you want to change the generate instance instructions, select the protocol you want from the **Instructions for** dropdown list on the right.
+> **Note:** The steps in this section are for generating one instance to test the **<StackSnippet snippet="protocol-name" inline/>** protocol or integration. <br>
+> If you want to change the generate instance instructions, select the protocol or integration you want from the **Instructions for** dropdown list on the right.
 
 1. From the **Test integration** page, click **Generate instance**.
 

@@ -1,5 +1,6 @@
 > **Note:** The **Universal logout properties** section only displays when you select **Universal Logout** along with the protocols that your integration supports from the **Select protocol** section.
 
+1. Specify the following properties if you want to integrate Universal Logout:
 | <div style="width:150px">Property</div> | &nbsp; | Description  |
 | ----------------- | --: | ------------ |
 | **Global token revocation endpoint** `*` | |Specify your [Global Token Revocation (GTR)](https://www.ietf.org/archive/id/draft-parecki-oauth-global-token-revocation-04.html) endpoint. If your endpoint URL is dynamic, use the variables that are specified in the **Integration variables** section. For example: `https://' + app.subdomain + '.example.org/strawberry/login`. See [Dynamic properties with Okta Expression Language](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#dynamic-properties-with-okta-expression-language).<br>The maximum field length is 1024 characters.|
@@ -10,3 +11,4 @@
 | **Partial support** | | Select if you only require partial universal logout support for your app. <br> **Note**: If you select this option, while clearing the user's session from Okta, the app only revokes the user's refresh tokens, which prevents the user from getting new access in the future. However, the existing user sessions aren't terminated until the user's existing access tokens expire or the user signs out of an app. </br>|
 
 `*` Required properties
+1. Click **Get started with testing** to save your edits and move to the testing section, where you need to enter your integration test details.
@@ -1,5 +1,7 @@
 > **Note:** The **Universal logout properties** section only displays when you select **Universal Logout** along with the protocols that your integration supports from the **Select protocol** section.
 
+1. Specify the following properties if you want to integrate Universal Logout:
+
 | <div style="width:150px">Property</div> | &nbsp; | Description  |
 | ----------------- | --: | ------------ |
 | **Global token revocation endpoint** `*` | |Specify your [Global Token Revocation (GTR)](https://www.ietf.org/archive/id/draft-parecki-oauth-global-token-revocation-04.html) endpoint. If your endpoint URL is dynamic, use the variables that are specified in the **Integration variables** section. For example: `https://' + app.subdomain + '.example.org/strawberry/login`. See [Dynamic properties with Okta Expression Language](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#dynamic-properties-with-okta-expression-language).<br>The maximum field length is 1024 characters.|
@@ -9,4 +11,5 @@
 | | **Issuer and Subject identifier** | Your integration uses the user identifier. |
 | **Partial support** | | Select if you only require partial universal logout support for your app. <br> **Note**: If you select this option, while clearing the user's session from Okta, the app only revokes the user's refresh tokens, which prevents the user from getting new access in the future. However, the existing user sessions aren't terminated until the user's existing access tokens expire or the user signs out of an app. </br>|
 
-`*` Required properties
+`*` Required properties
+1. Click **Get started with testing** to save your edits and move to the testing section, where you need to enter your integration test details.
@@ -2,6 +2,7 @@
 > * Universal Logout integrations are only supported for SAML 2.0 and OIDC protocols. If you want to submit a Universal Logout integration with SCIM provisioning, you must also submit an SSO integration with either SAML 2.0 or OIDC. For more information, see [Universal Logout](https://developer.okta.com/docs/guides/oin-universal-logout-overview).
 >* The **Universal logout properties** section only displays when you select **Universal Logout** along with the protocols that your integration supports from the **Select protocol** section.
 
+1. Specify the following properties if you want to integrate Universal Logout:
 | <div style="width:150px">Property</div> | &nbsp; | Description  |
 | ----------------- | --: | ------------ |
 | **Global token revocation endpoint** `*` | |Specify your [Global Token Revocation (GTR)](https://www.ietf.org/archive/id/draft-parecki-oauth-global-token-revocation-04.html) endpoint. If your endpoint URL is dynamic, use the variables that are specified in the **Integration variables** section. For example: `https://' + app.subdomain + '.example.org/strawberry/login`. See [Dynamic properties with Okta Expression Language](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#dynamic-properties-with-okta-expression-language).<br>The maximum field length is 1024 characters.|
@@ -12,3 +13,5 @@
 | **Partial support** | | Select if you only require partial universal logout support for your app. <br> **Note**: If you select this option, while clearing the user's session from Okta, the app only revokes the user's refresh tokens, which prevents the user from getting new access in the future. However, the existing user sessions aren't terminated until the user's existing access tokens expire or the user signs out of an app. </br>|
 
 `*` Required properties
+
+1. Click **Get started with testing** to save your edits and move to the testing section, where you need to enter your integration test details.
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1 @@
		For API service integration, do the testing manually.
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,2 @@
		* [SAML - Frequently Asked Questions](/docs/concepts/saml/faqs/)
		* [Okta Developer Forum: SAML](https://devforum.okta.com/search?q=saml)