This documentation outlines the SCIM (System for Cross-domain Identity Management) APIs implemented for managing roles within the Snapdocs ecosystem. Designed for seamless integration, these API support connections from Identify Providers (IDPs) such as Microsoft Entra ID, Okta, and other IDPs that support SCIM configurations.

The Snapdocs SCIM API is based on version 2.0 of the SCIM protocol.

Snapdocs SCIM Service Provider

Our SCIM service provider follows the SCIM 2.0 API as described in RFCs 7643 and 7644. You do not need to implement all aspects of the SCIM 2.0 specification to integrate your user information with Snapdocs. In general, you should not be implementing SCIM yourself, as your IDP already does. The information provided here is designed to aid you in configuring a SCIM connection in your IDP, not to enable you to write an API client yourself.

Authentication

Requests to the SCIM API must be authenticated with a secret token. Please contact your Snapdocs Customer Success Manager or Implementations Manager to acquire an authentication token.

Host

The following are the values for the Tenant URLs for the endpoints for our production and non-production environments.

Environment	Tenant URL
cs-demo0	https://api.cs-demo0.snpd.io/api/scim/v2
production	https://api.snapdocs.com/api/scim/v2

APIs

Supported Resources

We only support the User resource. Groups are not supported at this time.

Bulk operations are not supported. For more information on how the RFC describes the resource endpoints, see RFC 7644 SCIM Protocol Specification.

Supported Attributes

Below is an example POST body to create a user containing all supported attributes. Use this as a guide to which attributes you should map in your IDP. Other standard SCIM attributes are allowed, but will be ignored and won't be persisted or returned. We recommend that you not map them in your IDP. Most IDPs will continually attempt to update the user if the attributes it expects are not returned. Those updates will succeed, but will do nothing. To avoid needless updates to set ignored attributes, refrain from mapping unsupported attributes.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "externalId":"dschrute",
  "userName":"[email protected]",
  "active": true,
  "name":{
    "givenName": "Dwight",
    "familyName": "Schrute"
  },
  "title": "Assistant to the Regional Manager",
  "timezone": "America/New_York",
  "phoneNumbers":[
    {
      "value":"555-555-8377",
      "type":"work"
    },
    {
      "value":"555-555-8378",
      "type":"mobile"
    },
    {
      "value":"555-555-8379",
      "type":"fax"
    }
  ],
  "roles":[
    {
      "primary": true,
      "value": "closer"
    }
  ]
}

userName: required to be an email address, and the email address that the user will use to sign into Snapdocs
timeZone: if present, must be a US timezone in Olson format
roles - primary: required. Valid values include the following values. Note that roles in Snapdocs Closings are concentric, and are presented here in order of increasing access. Each role grants all the permissions of the roles above it.

Primary Role Value	Functionality Available
view_and_comment	Read only user role, limited to transactions they're added to.
closer	Role that can interact with the closing, perform actions. Limited to the transactions they're added to.
manager	Role that can interact with the closing, perform actions. Can interact with all closings.
admin	Manager role, with the ability to edit settings and add/remove users from the account.

Because Groups are not supported, you cannot use them to set roles. Roles must be set directly on the User resource.

📘
Note on roles for Entra
In Entra, the role can be set by defining app roles in your Snapdocs Entra application. Define four roles, each with a value matching a role name in the above table. Assign users (directly or via groups) to these app roles, and add a SCIM attribute mapping for the target attribute roles[primary eq true].value with the expression SingleAppRoleAssignment([appRoleAssignments]). Make sure not to assign multiple roles to a user, as there's no guarantee which will be provisioned by the expression in that case.

📘
Note on roles for Okta
In Okta, the role can be set as a user attribute with external name roles.^[primary==true].value. We recommend you define the attribute as an enum with type string. Here is an example of a working attribute configuration:

Operations

The Snapdocs SCIM integration supports these standard SCIM operations. Please note that DELETE is implemented by deactivating the user. Therefore, deleted users will still appear in search results as inactive.

Operation	HttpCommand	URL
Create	POST	`https://api.snapdocs.com/api/scim/v2/Users`
Read	GET	`https://api.snapdocs.com/api/scim/v2/Users/{id}`
Replace	PUT	`https://api.snapdocs.com/api/scim/v2/Users/{id}`
Delete	DELETE	`https://api.snapdocs.com/api/scim/v2/Users/{id}`
Update	PATCH	`https://api.snapdocs.com/api/scim/v2/Users/{id}`
Search	GET	`https://api.snapdocs.com/api/scim/v2/Users?ﬁlter={attribute}{op}{value}&startIndex={int}&count={int}`

Search Parameters

The filter attribute is optional. We have limited support for filters, including only the following two filters.

userName eq {value} - when looking for a specific user with only the userName (email) value
externalId eq {value}- when looking for a specific user with only the external identifier attirbute

We do not support sorting at this time. IDPs very rarely use more complicated filters, or sorting.

Paging parameters are optional. startIndex defaults to 1 and count defaults to 100 if not provided.