> ## Documentation Index > Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # SailPoint IdentityNow integration setup > Connect SailPoint IdentityNow to Living Security to import workforce identities and application accounts, and to run SailPoint workflows from playbooks. > [!NOTE] > > **This guide is for your SailPoint IdentityNow administrator.** It covers creating API > credentials inside SailPoint IdentityNow, which requires admin access to SailPoint IdentityNow — not to the > Living Security Platform. > > If you're the Living Security **program owner** and don't administer SailPoint IdentityNow, > send this page to whoever does. They complete Part A and hand the credentials back to you > (or enter them directly if you've invited them into the platform). > > Because setup produces sensitive key material, we recommend the > **delegated setup** path so the secret is never sent back to you. ## What this integration contributes SailPoint IdentityNow is an identity source. It adds people and their accounts to Living Security, not activity events. The connection reads two streams: | Stream | What it imports | SailPoint API | | - | - | - | | **Users** | Workforce identities — employees and contractors, with department and lifecycle state | `POST /v3/search` on the `identities` index | | **Accounts** | Your account inventory — the application accounts SailPoint holds for each connected system | `GET /v3/accounts` | Living Security uses the **Users** stream to match people across your other integrations. The **Accounts** stream stores your account inventory as imported records only. Living Security does not yet link those accounts to people, so the platform does not show which systems each person can access. You can also let playbooks run SailPoint workflows. That part is optional and has its own setup — see [Let playbooks run a SailPoint workflow](#optional-let-playbooks-run-a-sailpoint-workflow). ## What Living Security needs | Credential | Description | | - | - | | **Client ID** | The client ID of a SailPoint personal access token. | | **Client secret** | That token's secret. | | **Tenant subdomain** | The `` in `.identitynow.com` — the bare subdomain, not the full URL. | ### Required scopes The personal access token must carry these scopes. Each one comes from SailPoint's published API specification for the endpoint that uses it. | Scope | Used for | | - | - | | `sp:scopes:default` | The connection check (`GET /v3/public-identities`) | | `sp:search:read` | The **Users** stream (`POST /v3/search`) | | `idn:accounts:read` | The **Accounts** stream (`GET /v3/accounts`) | You can select `sp:scopes:all` instead. It gives the token every scope that its owner's user level allows, which includes these three. SailPoint recommends that you select only the scopes you need. ### Required user level Create the token as a user with the **Admin** user level (`ORG_ADMIN`). A personal access token acts with its owner's access. A more limited user level can return only part of your identities, or none. > [!NOTE] > > Use a **personal access token**, not an API client from **API Management**. SailPoint accepts the connection check only from a token that belongs to a user, so an API-management client fails to connect. ## Setup **1. Find your tenant subdomain** Your tenant subdomain is the part before `.identitynow.com` in your SailPoint URL. For `https://acme.identitynow.com`, the subdomain is `acme`. **2. Create a personal access token in SailPoint** 1. Sign in to SailPoint as a user with the **Admin** user level. 2. Open the menu under your user name, then select **Preferences**. 3. Select **Personal Access Tokens**, then **New Token**. 4. Enter a description, such as `Living Security Platform`. 5. Use the toggles to select the scopes `sp:scopes:default`, `sp:search:read`, and `idn:accounts:read`. 6. Select **Create Token**. 7. Copy the **Client ID** and the **Secret**. SailPoint shows the secret only once. **3. Allowlist Living Security's addresses** If your SailPoint tenant restricts API access by source IP address, allowlist both sets of addresses below before you connect. Living Security requests the access token itself and renews it continuously, so token requests and scheduled syncs leave from different networks. Skip this step if your tenant does not restrict API access by IP address. > [!WARNING] > > **SailPoint IdentityNow needs two sets of addresses, not one.** Living Security mints this > integration's access token on its own infrastructure and refreshes it continuously, so setup > traffic and sync traffic leave from different networks. Allowlist both sets in SailPoint IdentityNow, and > keep both in place — this is not a setup-only requirement. > > **Integration sync traffic** — the same in every region: > > `52.34.139.153/32`, `54.69.127.183/32`, `44.247.133.183/32`, > `52.26.211.56/32` > > **Platform traffic** — use only the row for the region that hosts your > organization: > > United States: `98.91.60.249/32`, `13.216.91.102/32` > > European Union: `34.246.236.210/32`, `52.31.102.238/32` > > Allowlist only the sync set and setup never completes. Allowlist only the platform set and > setup succeeds while every sync fails. See > [Configuring Integration Egress IP Addresses](https://docs.livingsecurity.com/integrations/managing/egress-ip-addresses.md) > for both failure signatures and the change policy. **4. Enter the credentials in the Living Security Platform** Completed by whoever holds Living Security access — the program owner, or the system admin if they've been invited (delegated setup). 1. Go to **Settings → Integrations → Catalog**, find the **SailPoint IdentityNow** tile, click **Connect**. 2. Fill in the fields below, then click **Connect**. Enter the tenant subdomain, the client ID, and the client secret, then connect. Living Security exchanges the token for a short-lived access token and renews it before it expires. You do not need to generate or rotate access tokens. If you delete or replace the personal access token in SailPoint, reconnect the tile with the new values. ## Optional: let playbooks run a SailPoint workflow A playbook step can run one of your SailPoint workflows for each person it targets. Skip this section if you only want to import identities and accounts. The workflow receives the person's SailPoint identity ID as `identityServiceId` in its input. Before a step can run a workflow, all of these must be true: 1. **The workflow starts with an External Trigger step and is enabled.** SailPoint runs a workflow from outside SailPoint only when it begins that way. A disabled workflow does not run, and the playbook step fails so the run does not report work that did not happen. 2. **An admin adds the workflow to the allowlist.** Open the SailPoint connection in the Living Security Platform and add the workflow ID under **Runnable workflows**. Living Security refuses a workflow that is not on the list before any request reaches SailPoint. An empty list blocks every workflow. 3. **An admin adds the workflow's OAuth client.** Under **Workflow OAuth clients**, select **Add client** next to the workflow, then enter its client ID and secret. ### Which OAuth client to use SailPoint binds each External Trigger workflow to exactly one OAuth client, with the `sp:workflow-execute:external` scope. It runs the workflow only for a token from that client. The connection's personal access token does not work here, even when it has every scope. > [!WARNING] > > Use the client that SailPoint already created for the workflow's External Trigger. Do not create a new one. A new client replaces the old one, and anything that still uses the old client stops working. The workflow ID appears in the workflow's URL in SailPoint, and in the response from SailPoint's `/v3/workflows` endpoint. ## Verify and troubleshoot After you connect, verify that the **Users** stream imports at least one identity. The **Accounts** stream can take longer on large tenants. > [accordion] 401 Unauthorized > > The client ID or secret is wrong, or the personal access token was deleted. Confirm that the token still exists under **Preferences → Personal Access Tokens**, then reconnect with the current values. > [accordion] 403 Forbidden > > The token is missing a required scope, or its owner's user level cannot read the data. Create a token with the scopes in [Required scopes](#required-scopes), as a user with the **Admin** user level, then reconnect. > > If you changed the scopes of an existing token, wait up to 30 minutes for SailPoint to apply the change, then reconnect. > > If you used an API client from **API Management**, replace it with a personal access token. > [accordion] The connection succeeds but imports no identities or accounts > > The token's owner can see only part of your tenant. Create the token as a user with the **Admin** user level. > [accordion] The tenant cannot be reached > > Enter only the subdomain — for example, `acme`, not `acme.identitynow.com` or `https://acme.api.identitynow.com`. > > If the subdomain is correct, check whether your SailPoint tenant restricts API access by source IP address. If it does, confirm that both sets of addresses from the **Allowlist Living Security's addresses** setup step are allowlisted: the integration sync traffic addresses and the platform traffic addresses for your region. > [accordion] A playbook step fails to run a workflow > > Check the three conditions in [Let playbooks run a SailPoint workflow](#optional-let-playbooks-run-a-sailpoint-workflow). A 401 from SailPoint usually means that the stored OAuth client is not the one bound to the workflow. For vendor-side details, see SailPoint's guide to [personal access tokens](https://developer.sailpoint.com/docs/api/authentication#generate-a-personal-access-token). *** ## Related resources ## Related topics - [Configuring Integration Egress IP Addresses](https://docs.livingsecurity.com/integrations/managing/egress-ip-addresses.md) - [Set up SCIM with SailPoint](https://docs.livingsecurity.com/features/settings/scim-sailpoint.md) - [Allowlisting Quickstart](https://docs.livingsecurity.com/getting-started/allowlisting.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.