CyberArk User Management API Guide

Auth method: CyberArk Identity OAuth 2.0 (client_credentials or authorization_code) for Privileged Cloud; session-based token (CyberArk-specific /auth endpoint) for self-hosted PAM

Setup steps

1. For Privileged Cloud: Register an OAuth2 service account application in CyberArk Identity Admin Portal under Apps > OAuth2 Client.
2. Assign the service account the required roles (e.g., Privilege Cloud Administrator) in CyberArk Identity.
3. Obtain a bearer token via POST to https://.id.cyberark.cloud/oauth2/platformtoken with grant_type=client_credentials, client_id, and client_secret.
4. Include the bearer token in the Authorization header: 'Authorization: Bearer '.
5. For self-hosted CyberArk PAM: POST credentials to /PasswordVault/API/auth/CyberArk/Logon to receive a session token, then pass it as the Authorization header value.

Required scopes

List Users

• Method: GET
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users
• Watch out for: Filter parameters (UserType, Search) are optional but recommended; unfiltered calls on large vaults can be slow.

Request example

GET /PasswordVault/API/Users?UserType=EPVUser&limit=50
Authorization: Bearer <token>

Response example

{
  "Users": [
    {"id": 12, "username": "jdoe", "userType": "EPVUser", "enableUser": true}
  ],
  "Total": 1
}

Get User Details

• Method: GET
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users/{id}
• Watch out for: The {id} is the numeric vault user ID, not the username string.

Request example

GET /PasswordVault/API/Users/12
Authorization: Bearer <token>

Response example

{
  "id": 12,
  "username": "jdoe",
  "firstName": "John",
  "lastName": "Doe",
  "email": "jdoe@example.com",
  "userType": "EPVUser",
  "enableUser": true
}

Create User

• Method: POST
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users
• Watch out for: initialPassword must meet vault password policy complexity; userType must match a licensed type available on the tenant.

Request example

POST /PasswordVault/API/Users
Authorization: Bearer <token>
Content-Type: application/json
{
  "username": "jdoe",
  "userType": "EPVUser",
  "initialPassword": "P@ssw0rd!"
}

Response example

{
  "id": 42,
  "username": "jdoe",
  "userType": "EPVUser",
  "enableUser": true
}

Update User

• Method: PUT
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users/{id}
• Watch out for: Uses PUT (full replacement semantics in some versions); omitting optional fields may reset them. Verify behavior on your version.

Request example

PUT /PasswordVault/API/Users/42
Authorization: Bearer <token>
Content-Type: application/json
{
  "email": "jdoe@newdomain.com",
  "enableUser": true
}

Response example

{
  "id": 42,
  "username": "jdoe",
  "email": "jdoe@newdomain.com",
  "enableUser": true
}

Delete User

• Method: DELETE
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users/{id}
• Watch out for: Deletion is permanent and removes the user from all safe memberships. Consider disabling (enableUser: false) instead for audit trail preservation.

Request example

DELETE /PasswordVault/API/Users/42
Authorization: Bearer <token>

Response example

HTTP 204 No Content

Activate / Unsuspend User

• Method: POST
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users/{id}/Activate
• Watch out for: Only applicable when user is suspended due to failed login attempts; does not re-enable a manually disabled account.

Request example

POST /PasswordVault/API/Users/42/Activate
Authorization: Bearer <token>

Response example

HTTP 200 OK

Add User to Group

• Method: POST
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/UserGroups/{groupId}/Members
• Watch out for: Group membership is managed separately from the user object; groupId must be retrieved via GET /UserGroups first.

Request example

POST /PasswordVault/API/UserGroups/5/Members
Authorization: Bearer <token>
Content-Type: application/json
{
  "memberId": 42,
  "memberType": "User"
}

Response example

HTTP 201 Created

Reset User Password

• Method: POST
• URL: https://<tenant>.privilegecloud.cyberark.cloud/PasswordVault/API/Users/{id}/ResetPassword
• Watch out for: Caller must have Manage Users permission in the vault. Password must comply with vault password policy.

Request example

POST /PasswordVault/API/Users/42/ResetPassword
Authorization: Bearer <token>
Content-Type: application/json
{
  "id": 42,
  "newPassword": "NewP@ss1!"
}

Response example

HTTP 200 OK

• Rate limits: CyberArk does not publish explicit rate limit tiers in official documentation. Limits are enforced at the platform level and may vary by deployment type (SaaS vs. self-hosted).
• Rate-limit headers: No
• Retry-After header: No
• Rate-limit notes: CyberArk recommends implementing exponential backoff. Concurrent session limits apply per user account. Contact CyberArk support for tenant-specific limits.
• Pagination method: offset
• Default page size: 0
• Max page size: 0
• Pagination pointer: limit / offset (used on list endpoints such as GetUsers; exact defaults not publicly documented)

• Webhooks available: No
• Webhook notes: CyberArk Privileged Cloud REST API does not offer native outbound webhooks for user lifecycle events. CyberArk Identity (the IdP layer) supports some event-driven integrations via its workflow engine but not a standard webhook subscription model.
• Alternative event strategy: Use CyberArk Identity's SIEM integration or Syslog/CEF event forwarding for audit events. For provisioning triggers, use SCIM inbound provisioning from an IdP (e.g., Azure AD/Entra ID) or poll the Users API on a schedule.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (CyberArk Identity / Workforce Identity)

• Endpoint: https://.id.cyberark.cloud/scim/v2

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

Limitations:

• SCIM provisioning is for CyberArk Identity (IdP) user directory, not directly for Privileged Cloud vault accounts; vault account creation requires separate PAM API calls or role-based auto-provisioning rules.
• SSO must be configured as a prerequisite for SCIM provisioning.
• Inbound SCIM from Azure AD/Entra ID is the primary tested and documented integration path; other IdPs may have limited support.
• SCIM token (OAuth 2.0 bearer) for SCIM endpoint is generated separately in the CyberArk Identity Admin Portal under Settings > SCIM.
• Enterprise plan required; not available on lower-tier Workforce Identity editions.

Three integration patterns cover the majority of identity lifecycle use cases. First, direct vault user provisioning: obtain an OAuth 2.

0 bearer token, POST to /PasswordVault/API/Users with username, userType, and initialPassword, capture the returned numeric id, then add group membership via POST /PasswordVault/API/UserGroups/{groupId}/Members. The userType field directly affects license consumption - use BasicUser where EPVUser is not required.

Second, inbound SCIM 2. 0 provisioning from Azure AD / Entra ID: generate a SCIM bearer token in Admin Portal → Settings → SCIM, configure the Entra ID Enterprise Application with endpoint https://.id.cyberark.cloud/scim/v2, map attributes, and enable sync.

SSO must be active before SCIM provisioning is enabled; this path populates the Identity directory only - Privileged Cloud vault access requires separate role or safe assignment.

Third, safe offboarding without audit loss: use PUT /PasswordVault/API/Users/{id} with {"enableUser": false} rather than DELETE; hard deletion is irreversible, removes all safe memberships, and should be avoided in regulated environments.

Building a complete identity graph across both the Identity directory (SCIM UUIDs) and the PAM vault (numeric integer IDs) requires explicit ID mapping - these identifiers are not interchangeable across the two APIs.

Provision a new Privileged Cloud vault user via REST API

1. Obtain OAuth 2.0 bearer token: POST https://.id.cyberark.cloud/oauth2/platformtoken with client_credentials grant.
2. Create the user: POST /PasswordVault/API/Users with username, userType (e.g., EPVUser), and initialPassword in the JSON body.
3. Capture the returned numeric user id from the response.
4. Add the user to the appropriate vault group: POST /PasswordVault/API/UserGroups/{groupId}/Members with memberId and memberType: 'User'.
5. Optionally set changePassOnNextLogon: true on the user record via PUT /PasswordVault/API/Users/{id}.

Watch out for: The OAuth token used must belong to a service account with 'Add Users' vault permission. Token expiry is 30 minutes; refresh before long provisioning loops.

Inbound SCIM provisioning from Azure AD / Entra ID to CyberArk Identity

1. In CyberArk Identity Admin Portal, navigate to Settings > SCIM and generate a SCIM bearer token.
2. In Azure AD / Entra ID, add CyberArk as an Enterprise Application and configure Provisioning mode to Automatic.
3. Enter the CyberArk SCIM endpoint (https://.id.cyberark.cloud/scim/v2) and the generated bearer token.
4. Map Azure AD attributes to CyberArk SCIM attributes (userName, name.givenName, name.familyName, emails, active).
5. Enable provisioning and run an initial sync; monitor provisioning logs in both Azure AD and CyberArk Identity.

Watch out for: SSO must be configured before SCIM provisioning is enabled. SCIM creates Identity directory users only; Privileged Cloud vault access requires additional role/safe assignment configuration in CyberArk.

Disable (suspend) a departing user without deleting vault history

1. Obtain bearer token via OAuth 2.0 client_credentials flow.
2. Look up the user's numeric vault ID: GET /PasswordVault/API/Users?Search=.
3. Disable the account: PUT /PasswordVault/API/Users/{id} with body {"enableUser": false}.
4. Optionally remove the user from all vault groups via DELETE /PasswordVault/API/UserGroups/{groupId}/Members/{memberId} for each group.
5. Retain the vault user record for audit and session recording history compliance.

Watch out for: Setting enableUser: false prevents login but preserves all audit trails and session recordings associated with the user ID. Hard deletion (DELETE /Users/{id}) is irreversible and should be avoided in regulated environments.

The most consequential architectural caveat is the split identity model: SCIM provisioning creates CyberArk Identity directory users but does not automatically create corresponding Privileged Cloud vault users. Any integration that assumes a single provisioning action covers both layers will leave vault access unprovisioned.

Maintaining a coherent identity graph across both systems requires explicit bridging logic - either via role-based auto-provisioning rules in CyberArk or a separate PAM API call sequence after SCIM sync completes.

A second trap is the PUT semantics on PUT /PasswordVault/API/Users/{id}: in some API versions this behaves as full replacement, meaning omitted optional fields may be reset to defaults; verify behavior on your specific tenant version before running bulk updates.

Webhooks are not available on the Privileged Cloud REST API; event-driven provisioning triggers must be implemented via scheduled polling of the Users API or inbound SCIM push from an upstream IdP.