> ## 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.

# Set up SCIM with SailPoint

> Connect a SailPoint SCIM 2.0 source to Living Security SCIM: authentication, schema discovery, account aggregation, a test account, and troubleshooting.

> [!NOTE]
>
> **Which SCIM setup applies to you?** These pages describe **Living Security SCIM**. Open the SCIM card in your settings. If the card shows **Set up SCIM**, or its **Mode** row says **Native SCIM**, these pages apply. If **Mode** says **Current SCIM**, your organization still uses the earlier SCIM setup. An admin can move it: see [Move from the earlier SCIM setup](https://docs.livingsecurity.com/features/settings/scim/connection.md#move-from-the-earlier-scim-setup). If the card says SCIM is set up and managed in the setup wizard, use [SCIM Provisioning](https://docs.livingsecurity.com/features/settings/scim.md).

SailPoint Identity Security Cloud and IdentityIQ manage Living Security accounts through the SailPoint SCIM 2.0 connector. This guide connects a SCIM 2.0 source to Living Security and tests it with one account.

> [!NOTE]
>
> Living Security has not certified SailPoint in a live run. Living Security SCIM follows the SCIM 2.0 standard (RFC 7643 and RFC 7644). Its tests replay the requests the SailPoint SCIM 2.0 connector sends: schema discovery, account aggregation by page and by cursor, and `active` changes by `PUT` and `PATCH`. The SailPoint menu names below come from SailPoint documentation and can differ in your version. Check each step with the [setup checklist](https://docs.livingsecurity.com/features/settings/scim/testing.md#the-setup-checklist) and the **Attributes** tab.

## What you need

* A Living Security admin with permission to manage SSO and SCIM settings.
* An administrator of SailPoint, or a [setup link](https://docs.livingsecurity.com/features/settings/scim/connection.md#send-a-setup-link-to-your-it-administrator) you send to one.
* SSO is not required. If you use SSO, the SCIM `userName` must be the same value your SSO sends as the NameID: the person's email address. See [SSO and sub-organizations](https://docs.livingsecurity.com/features/settings/scim/sso-and-sub-organizations.md).

## Set up the source

**1. Create the SCIM token in Living Security**

On the SCIM card, select **Set up SCIM**. Copy the **SCIM base URL** and the **Bearer token**. You can't see the token again. See [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md).

**2. Create a SCIM 2.0 source**

In SailPoint, create a source with the **SCIM 2.0** connector. Name it `Living Security`.

**3. Enter the connection**

1. Paste the SCIM base URL into **Base URL**.
2. Set **Authentication Type** to **API Token**, and paste the SCIM token. SailPoint sends it as a bearer token.
3. Select **Test Connection**.

> [!TIP]
>
> The Living Security **Checklist** shows **First request received** and **Connection test passed**.

**OAuth 2.0** with client credentials and **Basic Authentication** also work, but the SCIM card does not create them. Contact Living Security support if you need one. See [API reference: Authentication](https://docs.livingsecurity.com/features/settings/scim/api-reference.md#authentication).

**4. Discover the schema**

Run **Discover Schema**. SailPoint reads `GET /Schemas` and `GET /ResourceTypes` and builds the account and group schema from them. The schema includes the core user, the Enterprise extension and the Living Security extension.

When your source sends a custom extension attribute for the first time, Living Security adds that extension to `/Schemas`. Run **Discover Schema** again to see it.

**5. Aggregate accounts**

Run an account aggregation. SailPoint reads every user with paged `GET /Users` requests. Living Security returns an exact `totalResults`, and supports both page numbers and cursors.

**6. Create the provisioning policy**

In the source's **Create Account** policy, set these attributes:

| Living Security attribute | Source | Notes |
| - | - | - |
| `userName` | The identity's email | **Required.** The email your SSO sends. |
| `emails[type eq "work"].value` | The identity's email | **Required.** |
| `name.givenName`, `name.familyName` | First name, last name | |
| `title`, Enterprise `department` | Job title, department | |
| `active` | `true` | SailPoint disables an account by sending `active: false`. |

**7. Request one account**

Grant access to the Living Security source for one test identity.

## Test your setup

Follow [Test your SCIM setup](https://docs.livingsecurity.com/features/settings/scim/testing.md) with one person first. In short:

1. Select **Test Connection** on the source. On the Living Security **Checklist** tab, **First request received** and **Connection test passed** show **Done**.
2. Grant access to the Living Security source for the test identity. **First user received**, then **First user ready to sign in**, show **Done** within a few minutes.
3. Open the **Attributes** tab. Fix each item under **What to fix**, and check that **Attributes received** has the attributes you mapped. Compare with the [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md).
4. To see the exact request SailPoint sent, look at **Newest user** on the **Attributes** tab, or search the [SCIM events](https://docs.livingsecurity.com/features/settings/scim.md#review-received-scim-requests) for the person's email.
5. Ask the test person to sign in. **First sign-in by a SCIM user** shows **Done**.
6. Send one group. **First group received** shows **Done**.
7. Disable the test account in SailPoint. The person shows as deactivated in **Workforce → People**.

When every step shows **Done** or **Not used** and the **Health** tab shows **No warnings**, widen the scope in SailPoint.

## Troubleshoot

Each failed request has an `LS-SCIM` code in the error `detail`. SailPoint shows it in its provisioning logs. Open **Troubleshoot SCIM → Health** in Living Security for failed requests, held accounts and token expiry.

| Code | Meaning and fix |
| - | - |
| [LS-SCIM-1001](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1001) | Authentication failed. Copy the SCIM base URL and a current token from the SCIM card into SailPoint again. A token sent to another region's base URL also fails. |
| [LS-SCIM-1103](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1103) | A required attribute is missing. Map `userName` for users and `displayName` for groups. |
| [LS-SCIM-1104](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1104) | A value has the wrong type. Correct the mapping, for example `active` must be true or false. |
| [LS-SCIM-1107](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1107) | No usable email. Map the person's email to `emails[type eq "work"].value`. |
| [LS-SCIM-1108](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1108) | More than one primary email. Mark exactly one email as primary. |
| [LS-SCIM-1201](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1201) | The `userName` is already in use. Two SailPoint users map to the same `userName`, or SailPoint did not match an existing user. |
| [LS-SCIM-1303](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1303) | Invalid cursor. An aggregation sent a cursor with another filter or sort. Run the aggregation again. |
| [LS-SCIM-1307](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1307) | Expired cursor. A cursor walk waited more than 600 seconds between pages. Run the aggregation again. |
| [LS-SCIM-1601](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1601) | Rate limited. No action: SailPoint retries after the `Retry-After` time. |
| [LS-SCIM-1602](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1602) | Changes paused. No action: SailPoint retries. |
| [LS-SCIM-1604](https://docs.livingsecurity.com/features/settings/scim/errors.md#ls-scim-1604) | Internal error. Retry. If it continues, contact Living Security support with the output of **Copy diagnostics**. |

Some changes succeed in SailPoint but are held in Living Security, for example a change that would remove your last owner. The SCIM card shows **Held accounts**. See [Held changes](https://docs.livingsecurity.com/features/settings/scim/user-lifecycle.md#held-changes).

Every code is in the [SCIM error reference](https://docs.livingsecurity.com/features/settings/scim/errors.md). For a support request, select **Copy diagnostics** on the troubleshooting page. It has no names, email addresses or tokens.

## Related

* [SCIM attribute reference](https://docs.livingsecurity.com/features/settings/scim/attributes.md)
* [Test your SCIM setup](https://docs.livingsecurity.com/features/settings/scim/testing.md)
* [SCIM error reference](https://docs.livingsecurity.com/features/settings/scim/errors.md)
* [API reference and limits](https://docs.livingsecurity.com/features/settings/scim/api-reference.md)


## Related topics

- [Set up a SCIM connection](https://docs.livingsecurity.com/features/settings/scim/connection.md)
- [SailPoint IdentityNow integration setup](https://docs.livingsecurity.com/integrations/sailpoint-identitynow.md)
- [Living Security SCIM](https://docs.livingsecurity.com/features/settings/scim/overview.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.