Customers using Single Sign-on also have access to user provisioning & de-provisioning via dscout’s implementation of industry standard SCIM API. This feature allows customers to use their identity provider (IdP) to securely create dscout accounts for their users, keep their information (name, email, etc.) in sync, and revoke access to dscout (de-provision) .

Your dscout account owner and/or IdP administrator will manage access to dscout. When your dscout account is ready, they will provide login instructions.

If you're using Okta, refer to this guide

If you're not using Okta, read on or click the links below to learn more: 

Generating an API key

dscout account owners may generate an API key on the dscout settings page. Upon clicking “Generate API key” you will be prompted to name your key. You may then work with your organization’s IdP administrator to enter this key into your IdP’s authentication configuration for your dscout connection.

Screenshot 2024-05-31 at 10.52.54 AM.png

Using user provisioning (SCIM) exclusively

Once your API key is generated and you’ve successfully connected your identity provider to dscout, we strongly recommend toggling this setting on to only allow users to be managed via user provisioning (SCIM). Once this setting is on, you will no longer be able to add or remove users from the platform without first provisioning or de-provisioning them in your IdP.

Screenshot 2024-05-31 at 10.52.07 AM.png

What to do after provisioning

Users that are provisioned will be added to dscout as a viewer. Inside dscout you can choose the right role for new users by going to the Users page in account management. Additionally, you can add users to projects using either the “add users to projects” button on the projects page or using the “Add collaborators” button directly on the project.

API features

dscout’s SCIM API is based on the Open standard: System for Cross-domain Identity Management 2. Our implementation uses version 2.0 of the protocol. The API has been tested against Okta, OneLogin and Microsoft Entra ID (formerly named Azure Active Directory) and should work with any identity provider using the SCIM protocol.

Base URL and authentication

The API’s base URL is It expects the generated key to be provided in the requests header as a Bearer token.

# Curl example 
curl --request GET \
--url \
--header 'Authorization: Bearer YOUR_API_KEY'

Supported resources and attribute mapping


User attributes should be mapped as follows:


SCIM attribute External namespace Suggested mapping Description
userName urn:ietf:params:scim:schemas:core:2.0:User Mandatory. Maps to dscout’s user email.
givenName urn:ietf:params:scim:schemas:core:2.0:User name.givenName Mandatory. Maps to dscout’s user first name.
familyName urn:ietf:params:scim:schemas:core:2.0:User name.familyName Mandatory. Maps to dscout’s user last name.
title urn:ietf:params:scim:schemas:core:2.0:User title Recommended. Maps to dscout’s user job title.
timezone urn:ietf:params:scim:schemas:core:2.0:User timezone Recommended. Maps to dscout’s user time zone.


dscout’s API supports the following actions for users:

  • List all provisioned users
  • Create a new user
  • Get a user by ID
  • Replace user by ID
  • Update user attribute by ID

Please note the absence of a delete user action. When it is time to revoke dscout access for a user, our API expects SCIM clients to send a PUT or PATCH request with active=false. This action will make the user as deactivated, convert them to a free “viewer” seat and prevent them from logging into the platform. Additionally, your account manager can then chose to delete their record from user management in the account settings.



Currently, dscout supports group assignment but not push groups or memberships. Group assignment allows for assigning one or many directory groups to the dscout application in your IdP. Typically, the IdP will then call the users endpoints to provision and/or update those users.


Special callouts for specific identity providers

Microsoft Azure Entra ID

Microsoft has documented several known issues with their compliance against the SCIM 2.0 specification. dscout requires the addition of the their recommended query parameter
(?aadOptscim062020) in order for your integration to work properly. Your tenet URL should read as follows: 



After enabled SCIM, will all of my current users assigned to the application be migrated to dscout?

No. Only users updated or added after SCIM is enabled are added.

I’m an existing customer and have already added many users in dscout. How do I sync them with my identity provider?

In your identity provider, simply assign all relevant users to dscout. If the user does not already exist in dscout, their account will be provisioned. If the user was previously added manually in dscout, this process with sync those records (please confirm that user’s email in your identity provider matches the user’s email on their existing dscout account).

Will newly provisioned users receive a notification or invite from dscout?

No. dscout will not notify new users upon provisioning. We leave their notification in your hands after you’ve made any necessary adjustments to their role and/or added them to any workspaces or projects.

I deprovisioned a user from dscout in my identity provider, but they are still showing up in dscout.

Our SCIM API accepts “deactivation” requests from your identity provider, but we do not delete the user from your account. Instead, we mark them as “deprovisioned” and disallow the user from accessing dscout. You (or your account owner) can login to dscout once the user is deactivated and remove them.

How can I learn more about SCIM?

There are many good references on the internet. Here are a few:

Check back soon because push groups and memberships is currently in development and will allow the automatic mapping of directory groups to dscout seat types.

Was this article helpful?

0 out of 0 found this helpful
Have more questions? Submit a request