CrowdStrike User Management API Guide

Auth method: OAuth 2.0 (client credentials flow)

Setup steps

1. Log in to the Falcon console and navigate to Support & Resources > API Clients and Keys.
2. Click 'Add new API client', provide a name and description, and select the required scopes (e.g., User Management: Read and/or Write).
3. Copy the generated Client ID and Client Secret - the secret is shown only once.
4. POST to https://api.crowdstrike.com/oauth2/token with grant_type=client_credentials, client_id, and client_secret to obtain a Bearer token.
5. Include the token in all subsequent requests as Authorization: Bearer . Tokens expire after 30 minutes; re-authenticate as needed.

Required scopes

List user UIDs

• Method: GET
• URL: https://api.crowdstrike.com/users/queries/user-uids/v1
• Watch out for: Returns only UIDs; must follow up with the entities endpoint to retrieve full user objects.

Request example

GET /users/queries/user-uids/v1?offset=0&limit=100
Authorization: Bearer <token>

Response example

{
  "resources": ["uid-1234", "uid-5678"],
  "meta": {"pagination": {"offset": 0, "limit": 100, "total": 2}}
}

Get user details by UID

• Method: GET
• URL: https://api.crowdstrike.com/users/entities/users/v1
• Watch out for: Accepts multiple ids query params. Max batch size not explicitly documented; keep batches small (≤100).

Request example

GET /users/entities/users/v1?ids=uid-1234&ids=uid-5678
Authorization: Bearer <token>

Response example

{
  "resources": [
    {"uid": "uid-1234", "username": "user@example.com",
     "first_name": "Jane", "last_name": "Doe"}
  ]
}

Create user

• Method: POST
• URL: https://api.crowdstrike.com/users/entities/users/v1
• Watch out for: Roles must be assigned separately after creation. No password is set via API; user receives an email invitation.

Request example

POST /users/entities/users/v1
Authorization: Bearer <token>
Content-Type: application/json
{
  "username": "newuser@example.com",
  "first_name": "John",
  "last_name": "Smith"
}

Response example

{
  "resources": [
    {"uid": "uid-9999", "username": "newuser@example.com",
     "first_name": "John", "last_name": "Smith"}
  ]
}

Update user

• Method: PATCH
• URL: https://api.crowdstrike.com/users/entities/users/v1
• Watch out for: user_uuid is passed as a query parameter, not in the request body.

Request example

PATCH /users/entities/users/v1?user_uuid=uid-9999
Authorization: Bearer <token>
Content-Type: application/json
{
  "first_name": "Jonathan"
}

Response example

{
  "resources": [
    {"uid": "uid-9999", "first_name": "Jonathan", "last_name": "Smith"}
  ]
}

Delete user

• Method: DELETE
• URL: https://api.crowdstrike.com/users/entities/users/v1
• Watch out for: Deletion is immediate and irreversible. Revoke roles before deletion if auditing role history is required.

Request example

DELETE /users/entities/users/v1?user_uuid=uid-9999
Authorization: Bearer <token>

Response example

{
  "resources": ["uid-9999"],
  "errors": []
}

Get user roles

• Method: GET
• URL: https://api.crowdstrike.com/user-roles/queries/user-role-ids-by-user-uuid/v1
• Watch out for: Returns role ID strings only; use /user-roles/entities/user-roles/v1 to get full role metadata.

Request example

GET /user-roles/queries/user-role-ids-by-user-uuid/v1?user_uuid=uid-1234
Authorization: Bearer <token>

Response example

{
  "resources": ["falcon_admin", "detection_monitor"]
}

Grant roles to user

• Method: POST
• URL: https://api.crowdstrike.com/user-roles/entities/user-roles/v1
• Watch out for: Role IDs are case-sensitive strings. Use the /user-roles/queries/roles/v1 endpoint to enumerate valid role IDs first.

Request example

POST /user-roles/entities/user-roles/v1
Authorization: Bearer <token>
Content-Type: application/json
{
  "roleIds": ["falcon_admin"],
  "user_uuid": "uid-9999"
}

Response example

{
  "resources": [{"cid": "cid-abc", "role_id": "falcon_admin", "user_uuid": "uid-9999"}]
}

Revoke roles from user

• Method: DELETE
• URL: https://api.crowdstrike.com/user-roles/entities/user-roles/v1
• Watch out for: Both user_uuid and roleId are required query parameters. Revoking a non-assigned role returns an error.

Request example

DELETE /user-roles/entities/user-roles/v1?user_uuid=uid-9999&roleId=falcon_admin
Authorization: Bearer <token>

Response example

{
  "resources": ["falcon_admin"],
  "errors": []
}

• Rate limits: CrowdStrike enforces per-API-client rate limits. Specific numeric limits are not publicly documented; limits vary by endpoint and tenant tier. Rate limit responses return HTTP 429.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: On HTTP 429, inspect X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-RetryAfter headers. Implement exponential backoff. Limits are per API client credential pair.
• Pagination method: offset
• Default page size: 100
• Max page size: 500
• Pagination pointer: offset

• Webhooks available: No
• Webhook notes: CrowdStrike Falcon does not expose a general-purpose outbound webhook system for user management events via the public API.
• Alternative event strategy: Use the Falcon Event Streams API (streaming API) to consume audit and activity events in near-real-time, or poll the Audit Logs API for user lifecycle changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise ($184.99/device/year)

• Endpoint: Tenant-specific SCIM base URL provided within the Falcon console SSO/SCIM configuration page

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

Limitations:

• Requires SAML SSO to be configured and active before SCIM provisioning can be enabled.
• SCIM is configured through an IdP (Okta, Entra ID, OneLogin) - CrowdStrike acts as the SCIM service provider.
• Google Workspace is not listed as a supported IdP for SCIM integration.
• SCIM token is generated in the Falcon console and must be stored securely; rotation requires reconfiguring the IdP.
• Available only on Enterprise tier and above.

User provisioning is a two-step operation: POST /users/entities/users/v1 creates the account (triggering an email invitation - no password is set via API), then a separate POST /user-roles/entities/user-roles/v1 assigns roles using the uid returned from creation.

Role IDs are case-sensitive strings; enumerate valid IDs via GET /user-roles/queries/roles/v1 before attempting assignment.

Bulk user listing requires pagination via offset (default 100, max 500) against /users/queries/user-uids/v1, followed by batched GET requests to /users/entities/users/v1 with ids params - keep batches at or below 100 UIDs.

Role data is not embedded in the user object; a separate GET /user-roles/queries/user-role-ids-by-user-uuid/v1 call per user is required to build a complete user-role inventory.

For offboarding, deletion via DELETE /users/entities/users/v1 is immediate and irreversible with no soft-delete mechanism; if SCIM is active, prefer deactivating the user in the IdP with active:false over direct API deletion.

Provision a new user with a specific role

1. POST /oauth2/token to obtain a Bearer token with user-management:write scope.
2. POST /users/entities/users/v1 with username (email), first_name, last_name in the body to create the user account.
3. Note the returned uid from the response.
4. GET /user-roles/queries/roles/v1 to enumerate available role IDs and identify the target role.
5. POST /user-roles/entities/user-roles/v1 with the uid and desired roleIds array to assign the role.

Watch out for: The user receives an email invitation to set their password. Roles cannot be assigned in the same request as user creation.

Deprovision a user (offboarding)

1. POST /oauth2/token to obtain a Bearer token with user-management:write scope.
2. GET /users/queries/user-uids/v1 or search by username to retrieve the user's uid.
3. GET /user-roles/queries/user-role-ids-by-user-uuid/v1?user_uuid= to list assigned roles.
4. DELETE /user-roles/entities/user-roles/v1?user_uuid=&roleId= for each assigned role (optional but recommended for audit trail).
5. DELETE /users/entities/users/v1?user_uuid= to permanently remove the user.

Watch out for: Deletion is irreversible. If using SCIM, deactivating the user in the IdP (active:false) is the preferred offboarding path and avoids direct API deletion.

Bulk list all users and their roles

1. POST /oauth2/token to obtain a Bearer token with user-management:read scope.
2. GET /users/queries/user-uids/v1?offset=0&limit=500 and paginate using offset until all UIDs are collected.
3. Batch the UIDs and GET /users/entities/users/v1?ids=&ids=... (keep batches ≤100) to retrieve user details.
4. For each uid, GET /user-roles/queries/user-role-ids-by-user-uuid/v1?user_uuid= to retrieve role assignments.
5. Correlate user objects with their role lists for a complete user-role inventory.

Watch out for: This requires multiple API calls per user for role data. For large tenants, respect rate limits and implement backoff on HTTP 429 responses. Consider regional base URL differences if operating a multi-region deployment.

The most common integration failure pattern with the Falcon API is assuming a single-call provisioning model.

Role assignment is entirely decoupled from user creation - there is no inline roles field on the create request body - so any pipeline that does not explicitly handle the two-step flow will produce users with no roles assigned and no error surfaced.

API client credential scope is fixed at client creation time; adding a new scope requires editing or recreating the client in the Falcon console with no runtime scope elevation available.

Rate limits are enforced per API client but specific numeric thresholds are not publicly documented; always inspect X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-RetryAfter headers and implement exponential backoff on HTTP 429.

SCIM provisioning requires both an active SAML SSO configuration and Enterprise tier access - it cannot be enabled independently, and Google Workspace is not a supported IdP for SCIM. Teams building automated identity graph pipelines against Falcon must account for all of these constraints before assuming parity with simpler SCIM-native integrations.