Splunk User Management API Guide

Auth method: HTTP Basic Auth (username:password) or Splunk token-based authentication (Bearer token via /services/auth/login). OAuth 2.0 is not natively supported for the management REST API.

Setup steps

1. Obtain a session token by POST to /services/auth/login with username and password; extract the sessionKey from the response.
2. Pass the session token as an Authorization header: 'Authorization: Splunk '.
3. Alternatively, use HTTP Basic Auth with admin credentials directly on each request.
4. For token-based auth (Splunk 8.0+), create a token via Settings > Tokens in Splunk Web or POST /services/authorization/tokens, then use 'Authorization: Bearer '.
5. Ensure the calling user has the 'admin' or 'can_edit_users' capability for user-management operations.

Required scopes

List all users

• Method: GET
• URL: https://<host>:8089/services/authentication/users?output_mode=json&count=30&offset=0
• Watch out for: Default count is 30; use count=-1 to retrieve all users but this can be slow on large instances.

Request example

GET /services/authentication/users?output_mode=json&count=30 HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>

Response example

{
  "entry": [
    {
      "name": "jdoe",
      "content": {
        "email": "jdoe@example.com",
        "realname": "Jane Doe",
        "roles": ["user"]
      }
    }
  ]
}

Get a specific user

• Method: GET
• URL: https://<host>:8089/services/authentication/users/{username}?output_mode=json
• Watch out for: Returns 404 if the user does not exist; SAML/LDAP users may not appear until they have logged in at least once.

Request example

GET /services/authentication/users/jdoe?output_mode=json HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>

Response example

{
  "entry": [{
    "name": "jdoe",
    "content": {
      "email": "jdoe@example.com",
      "roles": ["user"],
      "locked-out": false
    }
  }]
}

Create a user

• Method: POST
• URL: https://<host>:8089/services/authentication/users
• Watch out for: Request body must be form-encoded (application/x-www-form-urlencoded), not JSON. The 'name' field cannot be changed after creation.

Request example

POST /services/authentication/users HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>
Content-Type: application/x-www-form-urlencoded

name=jdoe&password=Secret123&roles=user&email=jdoe@example.com

Response example

{
  "entry": [{
    "name": "jdoe",
    "content": {
      "email": "jdoe@example.com",
      "roles": ["user"]
    }
  }]
}

Update a user

• Method: POST
• URL: https://<host>:8089/services/authentication/users/{username}
• Watch out for: Splunk uses POST (not PUT/PATCH) for updates to existing resources. Omitting 'roles' does not preserve existing roles in all versions - always send the full desired roles list.

Request example

POST /services/authentication/users/jdoe HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>
Content-Type: application/x-www-form-urlencoded

roles=power&email=jdoe_new@example.com

Response example

{
  "entry": [{
    "name": "jdoe",
    "content": {
      "email": "jdoe_new@example.com",
      "roles": ["power"]
    }
  }]
}

Delete a user

• Method: DELETE
• URL: https://<host>:8089/services/authentication/users/{username}
• Watch out for: Cannot delete the built-in 'admin' user. SAML/LDAP-provisioned users deleted via REST may reappear on next SSO login if not also deprovisioned in the IdP.

Request example

DELETE /services/authentication/users/jdoe HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>

Response example

HTTP/1.1 200 OK
{}

List all roles

• Method: GET
• URL: https://<host>:8089/services/authorization/roles?output_mode=json
• Watch out for: Role names are case-sensitive and must match exactly when assigning to users.

Request example

GET /services/authorization/roles?output_mode=json HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>

Response example

{
  "entry": [
    {"name": "admin", "content": {"capabilities": ["admin_all_objects"]}},
    {"name": "user", "content": {"capabilities": ["search"]}}
  ]
}

Authenticate / get session token

• Method: POST
• URL: https://<host>:8089/services/auth/login
• Watch out for: Session tokens expire based on the 'tools.sessions.timeout' setting (default 1 hour). For long-running automation, use persistent Bearer tokens instead.

Request example

POST /services/auth/login HTTP/1.1
Host: <host>:8089
Content-Type: application/x-www-form-urlencoded

username=admin&password=changeme&output_mode=json

Response example

{
  "sessionKey": "abc123xyz...",
  "status": "200",
  "message": "OK"
}

Create a persistent auth token

• Method: POST
• URL: https://<host>:8089/services/authorization/tokens
• Watch out for: Token creation requires token authentication to be enabled in Splunk settings. Available in Splunk 8.0+.

Request example

POST /services/authorization/tokens HTTP/1.1
Host: <host>:8089
Authorization: Splunk <sessionKey>
Content-Type: application/x-www-form-urlencoded

name=automation-token&user=admin&expires_on=+30d

Response example

{
  "entry": [{
    "name": "automation-token",
    "content": {"token": "eyJra...", "status": "enabled"}
  }]
}

• Rate limits: Splunk's official documentation does not publish explicit REST API rate limits for user-management endpoints. Rate limiting behavior is not formally documented for the management API.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No documented rate limits or rate-limit response headers for the Splunk management REST API. Splunk Cloud may enforce undocumented throttling at the infrastructure level.

• Pagination method: offset

• Default page size: 30

• Max page size: 0

• Pagination pointer: count (number of results), offset (starting index). Use count=-1 to return all results (use with caution on large deployments).

• Webhooks available: No

• Webhook notes: Splunk does not provide native outbound webhooks for user-management events (user created, deleted, role changed). Splunk's alerting system can trigger HTTP POST actions based on search results, but this is not a user-management event webhook.

• Alternative event strategy: Use Splunk's audit log (index=_audit) with scheduled searches or real-time alerts to detect user-management changes and trigger downstream HTTP actions via alert actions.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Splunk Cloud Platform 9.1 or later; SAML SSO must be configured as a prerequisite. Not available for Splunk Enterprise on-premises.

• Endpoint: https://.splunkcloud.com/scim/v2

• Supported operations: GET /Users (list users), GET /Users/{id} (get user), POST /Users (create/provision user), PUT /Users/{id} (update user), PATCH /Users/{id} (partial update, activate/deactivate), DELETE /Users/{id} (deprovision user), GET /Groups (list groups/roles), GET /ServiceProviderConfig

Limitations:

• Requires Splunk Cloud Platform 9.1+; not supported on Splunk Enterprise (on-premises).
• SAML SSO must be configured before enabling SCIM provisioning.
• SCIM provisioning is validated with Okta, Microsoft Entra ID, and OneLogin; other IdPs may work but are not officially documented.
• Group push (role assignment via SCIM Groups) support may vary by IdP connector.
• SCIM endpoint URL is instance-specific and provided during IdP configuration setup.
• Google Workspace is not listed as a supported IdP for SCIM provisioning.

Three primary automation scenarios are supported by the API:

• Provision a local user with role assignment: POST to /services/authentication/users with a form-encoded body including name, password, roles, email, and realname. Always verify target role names first via GET /services/authorization/roles - a misspelled role name may result in silent no-role assignment depending on the Splunk version.

• Bulk role update: GET all users with count=-1 (use cautiously on large instances), then POST to /services/authentication/users/{username} for each target user. The roles parameter replaces the entire role list on every POST - always send the complete desired roles array, not an incremental diff.

• SCIM-based deprovisioning (Splunk Cloud + Okta): Unassigning a user in Okta triggers a PATCH /Users/{id} with active: false or a DELETE /Users/{id} to the Splunk SCIM endpoint. Note that SCIM deprovisioning does not terminate active SAML sessions; existing sessions persist until they expire naturally.

Provision a new local user with role assignment

1. Authenticate: POST /services/auth/login with admin credentials to obtain a sessionKey.
2. Verify the target role exists: GET /services/authorization/roles?output_mode=json.
3. Create the user: POST /services/authentication/users with form body: name=&password=&roles=&email=&realname=.
4. Confirm creation: GET /services/authentication/users/?output_mode=json and verify the response entry.

Watch out for: If the role name is misspelled or does not exist, Splunk may silently assign no role or return an error. Always verify role names first.

Deprovision a user via SCIM (Splunk Cloud + Okta)

1. Ensure Splunk Cloud Platform 9.1+ is running with SAML SSO configured.
2. In Okta, configure the Splunk Cloud SCIM application using the instance-specific SCIM endpoint URL and a SCIM Bearer token generated in Splunk.
3. In Okta, unassign the user from the Splunk Cloud application.
4. Okta sends a PATCH /Users/{id} request with 'active: false' or a DELETE /Users/{id} to the Splunk SCIM endpoint.
5. Verify the user is deactivated or removed in Splunk Cloud via the admin UI or GET /scim/v2/Users/{id}.

Watch out for: Deprovisioning via SCIM only removes the user from Splunk Cloud; active SAML sessions may persist until they expire. SCIM does not terminate existing sessions.

Bulk-update user roles via REST API

1. Authenticate and obtain a session token or use a persistent Bearer token.
2. GET /services/authentication/users?output_mode=json&count=-1 to retrieve all users.
3. For each user requiring a role change, POST /services/authentication/users/ with the updated roles= parameter (send the complete desired roles list).
4. Verify changes by re-fetching each user: GET /services/authentication/users/?output_mode=json.

Watch out for: Splunk's POST update for roles replaces the entire roles list, not appending. Always include all desired roles in the update request, not just the new ones.

Several non-obvious behaviors create integration risk. SAML and LDAP-federated users cannot be pre-created via the REST API - they are instantiated on first SSO login, and a REST DELETE will not prevent them from reappearing if the IdP account remains active. The built-in admin user cannot be deleted via the API under any circumstances.

On Splunk Cloud, direct access to port 8089 may be restricted by default and require source IP allowlisting through Splunk Support - this is an infrastructure constraint, not an API configuration.

For identity graph use cases requiring bidirectional sync, the SCIM endpoint is the correct integration surface, but its scope is limited: group push behavior for role assignment via SCIM Groups varies by IdP connector and is not uniformly documented. Pagination defaults to 30 results;

count=-1 returns all users but can be slow on large deployments and should not be used in high-frequency polling loops.