SentinelOne User Management API Guide

Auth method: API Token (Bearer token in Authorization header)

Setup steps

1. Log in to the SentinelOne Management Console as an admin user.
2. Navigate to Settings > Users > select your user profile.
3. Click 'Generate API Token' under the API Token section.
4. Copy the generated token - it is shown only once.
5. Include the token in all API requests as: Authorization: ApiToken
6. Tokens can be revoked and regenerated from the same user settings page.
7. Service user accounts can be created specifically for API access to avoid tying tokens to human accounts.

Required scopes

List Users

• Method: GET
• URL: /web/api/v2.1/users
• Watch out for: Must supply accountIds or siteIds query parameter to scope results; omitting may return unexpected cross-scope data.

Request example

GET /web/api/v2.1/users?limit=50&accountIds=<accountId>
Authorization: ApiToken <token>

Response example

{
  "data": [{"id":"123","email":"user@example.com","fullName":"Jane Doe","role":"Admin"}],
  "pagination": {"nextCursor":"abc123","totalItems":200}
}

Get User by ID

• Method: GET
• URL: /web/api/v2.1/users/{userId}
• Watch out for: Returns 404 if the token's scope does not include the target user's account/site.

Request example

GET /web/api/v2.1/users/123
Authorization: ApiToken <token>

Response example

{
  "data": {"id":"123","email":"user@example.com","fullName":"Jane Doe","role":"Admin","isActive":true}
}

Create User

• Method: POST
• URL: /web/api/v2.1/users
• Watch out for: An invitation email is sent automatically upon creation. The user must accept the invite before they can log in.

Request example

POST /web/api/v2.1/users
Authorization: ApiToken <token>
Content-Type: application/json
{
  "data": {"email":"newuser@example.com","fullName":"John Smith","role":"Viewer","accountId":"<accountId>"}
}

Response example

{
  "data": {"id":"456","email":"newuser@example.com","fullName":"John Smith","role":"Viewer","isActive":true}
}

Update User

• Method: PUT
• URL: /web/api/v2.1/users/{userId}
• Watch out for: Email address cannot be changed via API after account creation. Role changes take effect immediately.

Request example

PUT /web/api/v2.1/users/456
Authorization: ApiToken <token>
Content-Type: application/json
{
  "data": {"fullName":"John A. Smith","role":"Admin"}
}

Response example

{
  "data": {"id":"456","email":"newuser@example.com","fullName":"John A. Smith","role":"Admin"}
}

Delete User

• Method: DELETE
• URL: /web/api/v2.1/users/{userId}
• Watch out for: Deletion is permanent and cannot be undone. Consider setting isActive=false to disable without deleting.

Request example

DELETE /web/api/v2.1/users/456
Authorization: ApiToken <token>

Response example

{
  "data": {"success": true}
}

Get Current User (token owner)

• Method: GET
• URL: /web/api/v2.1/users/login/by-token
• Watch out for: Useful for validating token validity and retrieving the token owner's accountId for subsequent scoped queries.

Request example

GET /web/api/v2.1/users/login/by-token
Authorization: ApiToken <token>

Response example

{
  "data": {"id":"789","email":"admin@example.com","fullName":"API Admin","role":"Admin"}
}

List Roles

• Method: GET
• URL: /web/api/v2.1/user-roles
• Watch out for: Custom roles created in the console are returned alongside built-in roles. Role IDs differ per account.

Request example

GET /web/api/v2.1/user-roles?accountIds=<accountId>
Authorization: ApiToken <token>

Response example

{
  "data": [{"id":"r1","name":"Admin","description":"Full access"},{"id":"r2","name":"Viewer","description":"Read-only"}]
}

Revoke User API Token

• Method: POST
• URL: /web/api/v2.1/users/{userId}/revoke-api-token
• Watch out for: Immediately invalidates the target user's API token. The user must regenerate a new token from the console.

Request example

POST /web/api/v2.1/users/456/revoke-api-token
Authorization: ApiToken <token>

Response example

{
  "data": {"success": true}
}

• Rate limits: SentinelOne enforces API rate limits but does not publicly document specific numeric thresholds in official docs. Rate limiting is applied per API token.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: Official documentation does not specify exact request-per-minute limits or rate-limit response headers. HTTP 429 is returned when limits are exceeded. Contact SentinelOne support for tenant-specific limits.

• Pagination method: cursor

• Default page size: 10

• Max page size: 1000

• Pagination pointer: cursor (returned in pagination.nextCursor in response); limit controls page size

• Webhooks available: Yes

• Webhook notes: SentinelOne supports webhook notifications (called 'Notifications' in the console) for threat and activity events. They are configured via Settings > Notifications and are not user-management-specific.

• Alternative event strategy: For user lifecycle events, poll GET /web/api/v2.1/users with updatedAt__gt filter or use SCIM provisioning with an IdP that supports event-driven sync (e.g., Okta).

• Webhook events: Threat detected, Threat resolved, Agent disconnected, Policy violation, System health alerts

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Singularity Enterprise (custom pricing); SSO must be configured as a prerequisite

• Endpoint: https:///api/v1/scim (tenant-specific; generated within the SentinelOne SSO/SCIM configuration UI)

• Supported operations: Create user (POST /Users), Read user (GET /Users/{id}), List users (GET /Users), Update user (PUT /Users/{id}), Deactivate user (PATCH /Users/{id} with active=false), Push groups (POST /Groups, PATCH /Groups/{id})

Limitations:

• SCIM provisioning is officially documented only for Okta; Entra ID (Azure AD) and OneLogin may work but are not officially documented with step-by-step guides.
• SSO (SAML) must be fully configured before SCIM can be enabled.
• SCIM endpoint URL and bearer token are generated inside the SentinelOne console under Settings > SSO; the endpoint is tenant-specific and not a static public URL.
• User deprovisioning via SCIM deactivates the account (sets active=false) rather than deleting it.
• Group push maps to SentinelOne roles/sites; mapping must be configured manually in the IdP application.
• Available only on Singularity Enterprise tier per context data; not available on Core, Control, or Complete tiers.

Three scenarios cover the primary automation use cases:

Provision a new analyst: Fetch accountId via GET /users/login/by-token, list available roles via GET /user-roles?accountIds=<accountId>, then POST /users with email, fullName, role, and accountId.

An invitation email fires immediately on POST - if the user's email domain is not allowlisted in your mail relay, the invite will be silently blocked.

Confirm creation with GET /users/{newUserId}.

Deprovision a departing employee: Locate the user via GET /users?email=<email>&accountIds=<accountId>.

Set isActive=false via PUT /users/{userId} to block login without destroying the record, then revoke any active API token via POST /users/{userId}/revoke-api-token.

Use DELETE /users/{userId} only if permanent removal is required - deletion is irreversible.

If the user was provisioned via SCIM (source=scim), deprovision from the IdP instead;

direct API deletion can cause SCIM sync conflicts.

SCIM lifecycle automation via Okta: Requires Singularity Enterprise and a working SAML SSO configuration.

Generate the SCIM endpoint URL and bearer token from Settings > SSO in the SentinelOne console - this token is separate from user API tokens.

Configure SCIM 2.0 in the Okta SentinelOne app with Push New Users, Push Profile Updates, and Deactivate Users enabled.

Map userName to email and displayName to fullName.

If SSO is ever reconfigured, the SCIM bearer token may be regenerated;

Okta must be updated immediately to prevent provisioning failures.

Provision a new analyst user via REST API

1. Authenticate: obtain API token from console Settings > Users > API Token.
2. Retrieve accountId: GET /web/api/v2.1/users/login/by-token to get the token owner's accountId.
3. List available roles: GET /web/api/v2.1/user-roles?accountIds= to find the correct role name/ID.
4. Create user: POST /web/api/v2.1/users with email, fullName, role, and accountId in request body.
5. Verify creation: GET /web/api/v2.1/users/{newUserId} to confirm user record and isActive=true.
6. Inform user: SentinelOne automatically sends an invitation email; user must accept before first login.

Watch out for: The invitation email is sent immediately on POST. If the email domain is not allowlisted in your mail system, the invite may be blocked.

Deprovision a departing employee

1. Find user: GET /web/api/v2.1/users?email=&accountIds= to retrieve userId.
2. Disable account: PUT /web/api/v2.1/users/{userId} with isActive=false to immediately block login without data loss.
3. Revoke API token: POST /web/api/v2.1/users/{userId}/revoke-api-token to invalidate any active API tokens.
4. Optionally delete: DELETE /web/api/v2.1/users/{userId} if permanent removal is required (irreversible).

Watch out for: If the user was provisioned via SCIM (source=scim), deprovisioning should be performed from the IdP to keep SCIM state consistent; direct API deletion may cause sync conflicts.

Configure SCIM provisioning with Okta for automated lifecycle management

1. Confirm Singularity Enterprise license and that SAML SSO is already configured and working.
2. In SentinelOne console: navigate to Settings > SSO > enable SCIM provisioning; copy the generated SCIM endpoint URL and bearer token.
3. In Okta Admin: open the SentinelOne application > Provisioning tab > configure SCIM 2.0 with the copied endpoint URL and bearer token.
4. Enable provisioning features in Okta: Push New Users, Push Profile Updates, Deactivate Users.
5. Map Okta profile attributes to SentinelOne SCIM attributes (userName=email, displayName=fullName).
6. Configure group push in Okta to map Okta groups to SentinelOne roles/sites.
7. Test with a single user assignment before enabling for all users.

Watch out for: The SCIM bearer token generated in SentinelOne is separate from user API tokens. If SSO is reconfigured, the SCIM token may be regenerated and Okta must be updated to avoid provisioning failures.

Several non-obvious behaviors create integration risk. Pagination is cursor-based - pass pagination.nextCursor from each response as the cursor query parameter in the next request; the default page size is 10 with a maximum of 1000.

Omitting accountIds or siteIds on GET /users may return unexpected cross-scope data.

Rate limits are enforced per API token but exact numeric thresholds are not publicly documented. HTTP 429 is returned when limits are exceeded; no Retry-After header behavior is documented.

Contact SentinelOne support for tenant-specific limits before building high-frequency polling.

Bulk user operations are not supported - every create or update is a single API call. SSO-provisioned users (source=sso or source=scim) cannot have passwords managed via API; authentication is fully delegated to the IdP.

Email addresses cannot be changed via API after account creation. Custom role IDs differ per account - always fetch current role IDs from GET /user-roles rather than hardcoding them.