Tanium User Management API Guide

Auth method: API Token (session token or API key passed as HTTP header)

Setup steps

1. Log in to the Tanium Console as an administrator.
2. Navigate to Administration > Permissions > API Tokens.
3. Create a new API token, optionally scoping it to specific roles.
4. Copy the generated token value; it is shown only once.
5. Include the token in all API requests using the HTTP header: session:

Required scopes

List Users

• Method: GET
• URL: /api/v2/users
• Watch out for: Deleted users may appear in results unless filtered; check deleted_flag.

Request example

GET /api/v2/users?limit=100&offset=0
Headers:
  session: <api_token>

Response example

{
  "data": [
    {"id": 42, "name": "jdoe", "email": "jdoe@example.com", "active": true}
  ]
}

Get User by ID

• Method: GET
• URL: /api/v2/users/{id}
• Watch out for: Returns 404 if user is soft-deleted.

Request example

GET /api/v2/users/42
Headers:
  session: <api_token>

Response example

{
  "data": {
    "id": 42,
    "name": "jdoe",
    "roles": [{"id": 5, "name": "Analyst"}]
  }
}

Create User

• Method: POST
• URL: /api/v2/users
• Watch out for: Password is not set via API for local accounts; users must authenticate via SSO or receive a password reset.

Request example

POST /api/v2/users
Headers:
  session: <api_token>
  Content-Type: application/json
{
  "name": "jdoe",
  "email": "jdoe@example.com"
}

Response example

{
  "data": {
    "id": 43,
    "name": "jdoe",
    "active": true
  }
}

Update User

• Method: PUT
• URL: /api/v2/users/{id}
• Watch out for: PUT replaces the full user object; omitting optional fields may clear them. Use with care for role assignments.

Request example

PUT /api/v2/users/42
Headers:
  session: <api_token>
  Content-Type: application/json
{
  "email": "newemail@example.com",
  "active": false
}

Response example

{
  "data": {
    "id": 42,
    "email": "newemail@example.com",
    "active": false
  }
}

Delete User

• Method: DELETE
• URL: /api/v2/users/{id}
• Watch out for: Deletion is a soft delete; the user record is retained with deleted_flag=true.

Request example

DELETE /api/v2/users/42
Headers:
  session: <api_token>

Response example

{
  "data": {"id": 42}
}

List Roles

• Method: GET
• URL: /api/v2/roles
• Watch out for: Role IDs are required when assigning roles during user create/update.

Request example

GET /api/v2/roles
Headers:
  session: <api_token>

Response example

{
  "data": [
    {"id": 5, "name": "Analyst"},
    {"id": 6, "name": "Administrator"}
  ]
}

Get Current User (Whoami)

• Method: GET
• URL: /api/v2/session/info
• Watch out for: Useful for validating token validity and inspecting effective permissions.

Request example

GET /api/v2/session/info
Headers:
  session: <api_token>

Response example

{
  "data": {
    "id": 42,
    "name": "jdoe",
    "roles": [{"id": 6, "name": "Administrator"}]
  }
}

List API Tokens

• Method: GET
• URL: /api/v2/api_tokens
• Watch out for: Token values are not returned after initial creation; only metadata is retrievable.

Request example

GET /api/v2/api_tokens
Headers:
  session: <api_token>

Response example

{
  "data": [
    {"id": 1, "name": "CI Token", "expires_at": "2025-12-31T00:00:00Z"}
  ]
}

• Rate limits: Tanium's official documentation does not publicly specify numeric rate limits for the REST API.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate limit values or headers are documented in official sources. Tanium recommends avoiding high-frequency polling and using event-driven patterns where possible.

• Pagination method: offset

• Default page size: 100

• Max page size: 500

• Pagination pointer: offset / limit

• Webhooks available: No

• Webhook notes: Tanium does not expose a native webhook system for user management events in its official documentation.

• Alternative event strategy: Use Tanium Connect or scheduled REST API polling to detect user changes. Tanium Connect can forward data to external systems via HTTP, email, or file outputs.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Tanium Cloud (Enterprise)

• Endpoint: https:///scim/v2

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

Limitations:

• SCIM provisioning is only available on Tanium Cloud; not supported for on-premises deployments.
• An API token with Administrator role must be generated and provided to the IdP as the Bearer token.
• Group membership changes via SCIM map to Tanium computer groups, not roles directly.
• Password sync is not supported via SCIM; authentication relies on SSO.
• The SCIM endpoint URL is instance-specific and must be obtained from the Tanium Cloud console.

For provisioning, always call GET /api/v2/roles first to resolve role names to numeric IDs

these IDs are not stable across Tanium instances (dev, staging, prod will differ), so hardcoding them will cause silent misassignment.

Use POST /api/v2/users with the resolved role IDs in the roles array;

note that passwords cannot be set via API for local accounts, so new users must authenticate via SSO or a password reset flow.

For deprovisioning, DELETE /api/v2/users/{id} performs a soft delete only - the record persists with deleted_flag=true and will appear in GET /api/v2/users list responses unless explicitly filtered.

Before deletion, consider issuing PUT /api/v2/users/{id} with active: false to immediately block login, and separately revoke any API tokens the user holds via DELETE /api/v2/api_tokens/{token_id}.

For IdP sync via SCIM, SCIM groups map to Tanium computer groups, not roles;

role assignments must be managed separately through the REST API or console, which limits full lifecycle automation through SCIM alone.

Provision a new user with a specific role

1. Authenticate by generating an API token in the Tanium Console under Administration > API Tokens.
2. Call GET /api/v2/roles to retrieve the numeric ID for the desired role (e.g., 'Analyst').
3. Call POST /api/v2/users with name, email, and roles array containing the resolved role ID.
4. Verify the response returns the new user's id and active: true.

Watch out for: Role IDs differ between Tanium instances; never hardcode them - always resolve dynamically.

Deprovision a user on offboarding

1. Call GET /api/v2/users?name= or iterate the list to find the user's numeric id.
2. Call DELETE /api/v2/users/{id} to soft-delete the account.
3. Optionally call PUT /api/v2/users/{id} with active: false before deletion to immediately block login.
4. Revoke any API tokens associated with the user via DELETE /api/v2/api_tokens/{token_id}.

Watch out for: DELETE is a soft delete; the record persists with deleted_flag=true. Confirm your compliance requirements around data retention.

Sync users from an IdP using SCIM

1. Confirm the Tanium instance is on Tanium Cloud (Enterprise).
2. Generate an Administrator-scoped API token in the Tanium Console.
3. In your IdP (e.g., Okta, Azure AD), add a new SCIM 2.0 application.
4. Set the SCIM base URL to https:///scim/v2.
5. Set the authentication method to HTTP Header and provide the Tanium API token as the Bearer token.
6. Map IdP user attributes to SCIM standard attributes (userName → name, emails → email).
7. Enable provisioning features: Create Users, Update User Attributes, Deactivate Users.
8. Run a test sync and verify users appear in the Tanium Console under Administration > Users.

Watch out for: Group-to-role mapping is not direct; SCIM groups map to Tanium computer groups. Role assignments must be managed separately via the REST API or console.

The most dangerous API behavior is that PUT /api/v2/users/{id} is a full object replacement: omitting the roles array in a PUT payload silently removes all role assignments from the user. Any automation layer that constructs partial update payloads without first fetching and merging the existing user object will inadvertently strip access.

Pagination uses offset/limit with a default page size of 100 and a maximum of 500; Tanium does not document numeric rate limits or expose rate-limit headers, so polling-heavy integrations should implement conservative backoff. Tanium does not provide native webhooks for user management events;

event-driven patterns require either Tanium Connect forwarding or scheduled REST polling. For teams building against an identity graph using an MCP server with 60+ deep IT/identity integrations, the absence of stable role IDs across environments and the soft-delete behavior of the Users endpoint are the two most likely sources of data inconsistency at sync time.