Introduction to Sprinklr APIs

Sprinklr API v3 — the unified, OpenAPI-native interface to the Sprinklr platform.

Sprinklr APIs are RESTful web service APIs that let external systems read from and write to the data held in Sprinklr — cases, profiles, messages, campaigns, assets, listening topics, reporting, surveys, users, and platform configuration — so you can automate workflows and connect Sprinklr to the rest of your stack.

Sprinklr v3 APIs provide a robust, RESTful interface for managing customer experience data and processes across the Sprinklr platform. Designed for enterprise-scale integration, these APIs enable developers to interact with customer, asset, and reporting data, automate workflows, and connect Sprinklr with external systems. The v3 APIs follow OpenAPI 3.0 standards, support OAuth 2.0 and offer consistent response formats for ease of development and integration.

Your existing credentials work. v3 uses the same API key and OAuth access token as v1 and v2. Migrating an integration is primarily a matter of changing the path segment and adapting to the v3 envelope — not re-onboarding.

https://api3.sprinklr.com/{env}/api/v3

{env} is a server variable. The specification declares these values, with prod as the default:

prod · prod0 · prod2 · prod3 · prod4 · prod5 · prod6 · prod8 · prod11 · prod12 · prod15 · prod16 · prod17 · prod18 · prod19 · prod21 · prod25

An API key and token are environment-specific. A key generated for one environment cannot be used in another.

To find your environment: log in to the Sprinklr UI, right-click anywhere on the homepage, select View Page Source, and search (Ctrl+F / Cmd+F) for sentry-environment.

For the production environment (app.sprinklr.com), omit the {env} segment from the URL entirely.

Standard headers for a v3 call:

Omitting either credential returns 401 Unauthorized — the developer portal describes this as the "401 unauthorized (developer inactive)" error.

Successful v3 responses that use the shared APIResponse schema return:

{
  "data": { },
  "errors": []
}

Error — all three fields are required:

The dotted-key convention makes v3 errors machine-routable: branch on message rather than parsing prose.

Four reusable responses are defined once and referenced by operations across the whole specification:

All four return an ErrorResponse under application/json.

Developer Note. "Starting with the 26.1 release, it is recommended to use the Developer Tools built into the Sprinklr platform to create Developer Apps and to generate API Key and Secret." — Sprinklr Developer Portal, Getting Started.

Three steps to your first call: generate an API key → generate an access token → make the call.

Use Developer Tools inside the Sprinklr platform. It provides a centralized, self-service way to create and manage Developer Applications, API keys, and tokens without leaving Sprinklr.

Prerequisite permission: Configure Developer Apps.

1. Go to All Settings from the Sprinklr Launchpad.

   • Classic All Settings UI: Manage Customer → Developer Apps.
   • New All Settings UI: APIs and Integrations → Developer Apps.

2. Click + Create App and complete the form:

   Field	Required	Description
   App Name	Required	Name your application for the use case it serves. You can also tie the name to the environment — for example Sandbox or Production.
   App Description	Optional	The use case the application solves. Helps identify the objective when monitoring usage later.
   Callback URL	Required	The redirect_uri that tells the authorization server where to send the user back after successful account authorization. Must be a valid, publicly accessible URI, or the authorization call returns an error.
   Enable Mutual TLS Authentication	Optional toggle	Sprinklr APIs support mTLS as an additional layer of security, with client and server authenticating each other using their respective TLS certificates.

3. Save, then open ⋮ → Manage API Key/Token and click + API Key. Copy the key and secret from the pop-up — the secret is masked afterwards.

Important. Developer apps, API keys, secrets, and access tokens created at dev.sprinklr.com are not synchronized with, or reflected in, the Developer Tools inside the Sprinklr platform. Pick one path per integration.

Prerequisite: you must be assigned the Generate Token permission within the Sprinklr platform. This ensures only authorized users can generate tokens and access Sprinklr APIs.

In-platform (Developer Tools): click Generate Token, authenticate with your credentials or Continue with SSO, then complete two-factor authentication with the code sent to your registered email. The access token, refresh token, and expiry date appear once — save them, they cannot be recovered.

Via OAuth 2.0 authorization code grant — a two-step flow:

# Step 1 — run in a browser to obtain a code
https://api3.sprinklr.com/{env}/oauth/authorize?client_id={apikey}&response_type=code&redirect_uri={redirect_uri}

# Step 2 — POST to exchange the code for a token
https://api3.sprinklr.com/{env}/oauth/token?client_id={apikey}&client_secret={secret}&redirect_uri={redirect_uri}&grant_type=authorization_code&code={code}

Set Content-Type: application/x-www-form-urlencoded. Parameters may be sent either as query parameters or as body parameters — both methods are supported.

Response:

{
  "access_token": "[token]",
  "refresh_token": "[token]",
  "token_type": "Bearer",
  "expires_in": 2591999
}

Critical constraints:

• The authorization code is valid for 10 minutes. If you do not complete the token exchange within 10 minutes, repeat the access process.
• expires_in is 2591999 seconds (just under 30 days) in the documented response.
• Only one token can exist per API key. If you run multiple stateless instances, generate a separate API key and token pair for each. Generating a new token also updates the refresh token — if application B generates a token using application A's API key, application A's token and refresh token are invalidated.
• Tokens remain valid as long as the authenticated user's Sprinklr password is valid. If the password changes, refresh the token to receive a new access_token.
• If you send the key and secret as query parameters and receive a 411 Length-Required error, add a Content-Length: 0 header.
• Use a service account. Create a service user with an email group in the Sprinklr platform and grant it the necessary access, so the token is not tied to an individual who may leave the organization.
• Ensure the right workspaces are granted access while authorizing — you can only fetch data from workspaces the token has been given access to.

Sprinklr supports OAuth 2.0 Authorization Code Grant, Client Credentials Grant, and JWT certificate-based token generation. Code grant is a three-legged flow among the resource server, the resource owner, and the client; client credentials requires setting up a default user for generating the access token.

The simplest way to confirm your credentials work is the current user endpoint (MeApiV3_getCurrentUser, tag User V3):

curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/me' \
  -H 'Authorization: ******' \
  -H 'Key: {apikey}' \
  -H 'Accept: application/json'

A 200 confirms your key, token, and environment all line up. A 401 means one of the three is wrong.

(Illustrative example. Credentials are placeholders — replace ****** with Bearer {access_token}, {apikey} with your API key, and {env} with your environment identifier. No call was executed to produce this guide.)

The Sprinklr API governance model is directly dependent on the Sprinklr user's role and permission governance model. An API key is created for a user, so all permissions and roles tied to that user apply equally to the associated API key.

There are four types of users in Sprinklr:

1. Partner Admin (highest level of access)
2. Partner User
3. Client Admin
4. Client User (lowest level of access)

Key rules:

• Within a client environment, client-level roles and permissions override partner-level ones. If a user is associated with both a Partner Role and a Client Role, the Client Role access supersedes the Partner Role permissions.
• You cannot make an API call — even with valid Sprinklr login credentials — if you do not hold the required role or permission.
• Role-based permissions provide basic access, but some content or assets require additional permissions. Account permission is required to view content from, engage with, or publish from specific accounts.
• The access token automatically carries the roles and permissions of the user who generated it.

Worked example: user PA1 has permission to see SAM asset A123 but not A567. When PA1's API key k123 is used to access SAM assets, the API returns A123 and not A567. Similarly, if a user is granted access only to client Y1 and attempts to read data from client Y2's SAM, the call returns 401 Unauthorized.

This is why v3 declares a distinct 403 Forbidden — Insufficient permissions alongside 401 Unauthorized — Missing or invalid authentication: 401 means who are you, 403 means you are known but not entitled.

Sprinklr customers with Enterprise licenses are entitled to make use of Sprinklr APIs to export and update data within Sprinklr.

1. Change the path segment from /api/v2/ to /api/v3/. The host and {env} convention are unchanged.
2. Keep your credentials. The same API key and OAuth access token authenticate v3 calls.
3. Adapt to the envelope. Read the payload from data and check errors for the id/code/message triple. Branch on the dotted message key.
4. Re-check parameter locations. Several v3 endpoints moved identifiers that were v2 path parameters into query parameters. Verify each endpoint against its v3 reference page rather than assuming a mechanical version swap.
5. Re-test permissions. v3 operations declare 403 explicitly; a call that silently returned empty data in v2 may now return 403.
6. Regenerate the specification-driven parts of your client. Because v3 ships as a single OpenAPI 3.0.3 document, you can regenerate models and clients instead of hand-writing them.
7. Read the per-API migration section. Each v3 developer guide on this portal carries a V2 → V3 migration section with an endpoint map and a field map for that API.

v2 and v1 remain documented on this portal. v3 is the recommended target for new integrations.

1. Register with a service account email, not an individual's, so credentials survive staff changes.
2. One API key and token pair per running instance — a second token generated against the same key invalidates the first.
3. Never commit credentials. Keys, secrets, access tokens, and refresh tokens do not belong in source control, Postman collections, support tickets, or documentation.
4. Match the token to the environment. Keys and tokens are environment-specific and will not work across environments.
5. Grant the narrowest workspace access the integration needs at authorization time.
6. Handle 401 by refreshing, not by retrying the same token in a loop.
7. Read errors even on 200 — the envelope carries an errors array independently of the HTTP status.
8. Do not assume undeclared behaviour. If rate limits, pagination defaults, or retry semantics are not stated on the endpoint's reference page, confirm them before depending on them.
9. Enable mTLS on the Developer App when your security posture requires mutual certificate authentication.
10. Rotate deliberately. API keys and secrets do not expire and remain static; they can only be deleted or disabled from the Sprinklr developer account.

• Enablement: some APIs are gated and must be switched on for your environment. Contact your Success Manager or Sprinklr Support.
• Permissions: the Generate Token and Configure Developer Apps permissions are granted from within the Sprinklr platform by an administrator.
• Registration email not arriving: check your Spam folder. If it is not there, ask your IT team whether a rule rejects mail sent via AWS SES, and whitelist AWS SES sending on behalf of the Sprinklr API address.