Sprinklr User Management API Guide

Auth method: OAuth 2.0 (client credentials and authorization code flows)

Setup steps

1. Log in to the Sprinklr platform as an Admin and navigate to Settings > API Management.
2. Create an API App to obtain a Client ID and Client Secret.
3. Request an access token via POST to https://api.sprinklr.com/oauth/token using client_credentials grant type.
4. Include the returned Bearer token in the Authorization header for all subsequent API requests.
5. Tokens expire; implement refresh logic using the refresh_token if using authorization code flow.

Required scopes

List Users

• Method: GET
• URL: https://api.sprinklr.com/api/v2/users
• Watch out for: page is zero-indexed. Omitting pageSize defaults to 50.

Request example

GET /api/v2/users?page=0&pageSize=50
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id":"u_123","username":"jdoe@acme.com","status":"ENABLED"}
  ],
  "totalCount": 1
}

Get User by ID

• Method: GET
• URL: https://api.sprinklr.com/api/v2/users/{userId}
• Watch out for: Returns 404 if user does not exist in the authenticated environment.

Request example

GET /api/v2/users/u_123
Authorization: Bearer {access_token}

Response example

{
  "id": "u_123",
  "username": "jdoe@acme.com",
  "email": "jdoe@acme.com",
  "status": "ENABLED",
  "roleIds": ["role_456"]
}

Create User

• Method: POST
• URL: https://api.sprinklr.com/api/v2/users
• Watch out for: username must be unique across the environment. Duplicate usernames return a 409 conflict.

Request example

POST /api/v2/users
Authorization: Bearer {access_token}
Content-Type: application/json

{"username":"jdoe@acme.com","email":"jdoe@acme.com","firstName":"Jane","lastName":"Doe","roleIds":["role_456"]}

Response example

{
  "id": "u_789",
  "username": "jdoe@acme.com",
  "status": "ENABLED"
}

Update User

• Method: PUT
• URL: https://api.sprinklr.com/api/v2/users/{userId}
• Watch out for: PUT replaces the full user object; omitting optional fields may reset them. Use carefully.

Request example

PUT /api/v2/users/u_789
Authorization: Bearer {access_token}
Content-Type: application/json

{"firstName":"Jane","lastName":"Smith","roleIds":["role_456","role_789"]}

Response example

{
  "id": "u_789",
  "firstName": "Jane",
  "lastName": "Smith",
  "status": "ENABLED"
}

Deactivate User

• Method: PUT
• URL: https://api.sprinklr.com/api/v2/users/{userId}
• Watch out for: Sprinklr does not expose a dedicated PATCH or deactivate endpoint; status change is done via PUT.

Request example

PUT /api/v2/users/u_789
Authorization: Bearer {access_token}
Content-Type: application/json

{"status":"DISABLED"}

Response example

{
  "id": "u_789",
  "status": "DISABLED"
}

Delete User

• Method: DELETE
• URL: https://api.sprinklr.com/api/v2/users/{userId}
• Watch out for: Deletion is permanent. Prefer setting status=DISABLED for reversible deactivation.

Request example

DELETE /api/v2/users/u_789
Authorization: Bearer {access_token}

Response example

HTTP 204 No Content

List Roles

• Method: GET
• URL: https://api.sprinklr.com/api/v2/roles
• Watch out for: Role IDs are environment-specific; do not reuse IDs across different Sprinklr environments.

Request example

GET /api/v2/roles
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id":"role_456","name":"Community Manager"},
    {"id":"role_789","name":"Admin"}
  ]
}

Get Token (OAuth 2.0)

• Method: POST
• URL: https://api.sprinklr.com/oauth/token
• Watch out for: Tokens expire in 24 hours by default. Implement token refresh or re-issuance before expiry.

Request example

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Response example

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 86400
}

• Rate limits: Sprinklr enforces per-app rate limits on API calls. Specific numeric limits are not publicly documented in detail; limits vary by plan and API app configuration.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: Official docs do not explicitly document rate-limit response headers or Retry-After behavior. Contact Sprinklr support for app-specific limits.
• Pagination method: offset
• Default page size: 50
• Max page size: 100
• Pagination pointer: page / pageSize

• Webhooks available: No
• Webhook notes: Sprinklr's public developer documentation does not describe user-management-specific webhook events. Webhooks are available for social listening and engagement events, not user lifecycle events.
• Alternative event strategy: Poll GET /users with a timestamp filter or use SCIM provisioning events via your IdP (Okta, Entra ID) for user lifecycle notifications.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://api.sprinklr.com/scim/v2

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PUT /Users/{id}, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, POST /Groups, PATCH /Groups/{id}

Limitations:

• SSO must be configured and active before SCIM provisioning can be enabled.
• SCIM is only available on the Enterprise plan.
• SCIM endpoint URL and Bearer token are generated within Sprinklr's SSO/SCIM settings and must be copied into the IdP (Okta or Entra ID).
• Group push maps to Sprinklr user groups, not roles; role assignment still requires manual configuration or API.
• Google Workspace and OneLogin are not listed as supported IdPs for SCIM in official docs.

Three primary automation scenarios are well-supported by the API:

Provisioning via REST: Fetch roleIds from GET /api/v2/roles first - they are environment-scoped and not portable.

Then POST /api/v2/users with username, email, firstName, lastName, and roleIds.

The username field must be unique;

a duplicate returns HTTP 409.

Check existence with GET /users?username= before creating to avoid collision errors in idempotent pipelines.

Deprovisioning via REST: Retrieve the user's id via GET /api/v2/users filtered by email or username, then issue PUT /api/v2/users/{userId} with {"status":"DISABLED"}.

This preserves audit history and is reversible.

DELETE /api/v2/users/{userId} is permanent - prefer DISABLED for any environment with compliance or audit requirements.

SCIM auto-provisioning with Okta or Entra ID: SSO (SAML) must be fully active before SCIM can be enabled.

Generate the SCIM Base URL and Bearer token from Settings → Security → SCIM Provisioning, then configure the IdP connector.

Note that group push maps to Sprinklr user groups, not permission roles - role assignment remains a separate step outside the SCIM sync loop.

Google Workspace and OneLogin are not listed as supported IdPs in official documentation.

Provision a new employee via REST API

1. Obtain OAuth 2.0 access token via POST /oauth/token with client_credentials.
2. Retrieve available role IDs via GET /api/v2/roles to identify the correct roleId for the new user.
3. POST /api/v2/users with required fields: username, email, firstName, lastName, roleIds.
4. Store the returned id for future updates or deactivation.

Watch out for: username must be unique; if the user already exists (e.g., from a previous import), the API returns 409. Check existence with GET /users?username= before creating.

Deprovision a departing employee

1. Obtain a fresh access token if the current one is near expiry.
2. Look up the user's Sprinklr id via GET /api/v2/users filtering by username or email.
3. Set status to DISABLED via PUT /api/v2/users/{userId} with {"status":"DISABLED"} to revoke access while preserving audit history.
4. Optionally call DELETE /api/v2/users/{userId} for full removal if data retention is not required.

Watch out for: Deletion is irreversible. Prefer DISABLED status for compliance and audit trail preservation.

Set up SCIM auto-provisioning with Okta

1. Confirm Enterprise plan is active and SSO (SAML) is fully configured in Sprinklr Settings > Security.
2. In Sprinklr, navigate to Settings > Security > SCIM Provisioning and enable SCIM to generate the SCIM Base URL and Bearer token.
3. In Okta, add the Sprinklr app from the Okta Integration Network and navigate to the Provisioning tab.
4. Enter the Sprinklr SCIM Base URL and Bearer token into Okta's SCIM connector settings.
5. Enable the desired provisioning features: Create Users, Update User Attributes, Deactivate Users.
6. Assign users or groups in Okta to trigger initial provisioning sync.

Watch out for: SCIM will not activate if SSO is not already live. Group push maps to Sprinklr user groups, not permission roles - role assignment must be handled separately.

The most consequential API caveat is that PUT /users/{userId} replaces the full user object - omitting any optional field may silently reset it. Always fetch the current object before issuing a PUT to avoid unintended data loss.

A second structural trap: user IDs are environment-scoped, so the same individual will have different id values across Sprinklr environments; any identity graph integration must store and resolve IDs per environment, not globally.

Role IDs share the same constraint - they cannot be reused across environments and must be retrieved fresh from each target before provisioning. Finally, the developer portal and help center are separate properties with overlapping but non-identical documentation;

some endpoint details and schema fields appear in only one of the two, making complete API coverage dependent on consulting both sources.