Delinea User Management API Guide

Auth method: OAuth 2.0 (client credentials and resource owner password credentials grants); SCIM endpoints use a static Bearer token generated in the Delinea Platform admin console

Setup steps

1. Navigate to Delinea Platform Admin > Integrations > API Clients and create a new API client to obtain a client_id and client_secret.
2. POST to https://.delinea.app/identity/connect/token with grant_type=client_credentials, client_id, client_secret, and scope to receive an access_token.
3. Include the access_token as 'Authorization: Bearer ' on all REST API requests.
4. For SCIM provisioning, navigate to Admin > Integrations > SCIM and generate a dedicated SCIM Bearer token; configure this token in your IdP (Okta, Entra ID) as the API token.

Required scopes

List Users

• Method: GET
• URL: https://<tenant>.delinea.app/api/v1/users
• Watch out for: skip/take pagination; max take=100. Filter support varies by platform version.

Request example

GET /api/v1/users?skip=0&take=25
Authorization: Bearer <access_token>

Response example

{
  "data": [
    {"id":"uuid","userName":"jdoe@example.com","active":true}
  ],
  "total": 150,
  "skip": 0,
  "take": 25
}

Get User

• Method: GET
• URL: https://<tenant>.delinea.app/api/v1/users/{id}
• Watch out for: Use the platform UUID, not the userName, as the path parameter.

Request example

GET /api/v1/users/abc-123
Authorization: Bearer <access_token>

Response example

{
  "id": "abc-123",
  "userName": "jdoe@example.com",
  "displayName": "Jane Doe",
  "active": true,
  "roles": ["User"]
}

Create User

• Method: POST
• URL: https://<tenant>.delinea.app/api/v1/users
• Watch out for: userName must be unique across the tenant. Email is required for notification delivery.

Request example

POST /api/v1/users
Authorization: Bearer <access_token>
Content-Type: application/json
{
  "userName": "jdoe@example.com",
  "displayName": "Jane Doe",
  "active": true
}

Response example

{
  "id": "abc-123",
  "userName": "jdoe@example.com",
  "active": true
}

Update User (partial)

• Method: PATCH
• URL: https://<tenant>.delinea.app/api/v1/users/{id}
• Watch out for: Only include fields to be changed. Full PUT replacement may also be supported depending on platform version.

Request example

PATCH /api/v1/users/abc-123
Authorization: Bearer <access_token>
Content-Type: application/json
{
  "active": false
}

Response example

{
  "id": "abc-123",
  "userName": "jdoe@example.com",
  "active": false
}

Delete User

• Method: DELETE
• URL: https://<tenant>.delinea.app/api/v1/users/{id}
• Watch out for: Deletion is permanent. Consider setting active=false to disable without data loss.

Request example

DELETE /api/v1/users/abc-123
Authorization: Bearer <access_token>

Response example

HTTP 204 No Content

SCIM List Users

• Method: GET
• URL: https://<tenant>.delinea.app/scim/v2/Users
• Watch out for: SCIM Bearer token is separate from the REST API OAuth token. Tokens are generated in the SCIM integration settings.

Request example

GET /scim/v2/Users?startIndex=1&count=25
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 50,
  "startIndex": 1,
  "itemsPerPage": 25,
  "Resources": [{"id":"abc-123","userName":"jdoe@example.com"}]
}

SCIM Create User

• Method: POST
• URL: https://<tenant>.delinea.app/scim/v2/Users
• Watch out for: IdP must send externalId for reliable correlation on subsequent PATCH/PUT operations.

Request example

POST /scim/v2/Users
Authorization: Bearer <scim_token>
Content-Type: application/scim+json
{
  "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName":"jdoe@example.com",
  "active":true
}

Response example

{
  "id": "abc-123",
  "userName": "jdoe@example.com",
  "active": true,
  "meta": {"resourceType":"User"}
}

SCIM Patch User (deactivate)

• Method: PATCH
• URL: https://<tenant>.delinea.app/scim/v2/Users/{id}
• Watch out for: Delinea may return 200 or 204 on PATCH; IdP connectors should handle both. Deactivation does not remove PAM vault access immediately; vault session cleanup is asynchronous.

Request example

PATCH /scim/v2/Users/abc-123
Authorization: Bearer <scim_token>
Content-Type: application/scim+json
{
  "schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations":[{"op":"replace","path":"active","value":false}]
}

Response example

HTTP 204 No Content
(or 200 with updated user object depending on platform version)

• Rate limits: Delinea does not publish explicit rate limit tiers in public documentation. Throttling behavior is present but limits are not disclosed per plan.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: No official rate limit figures found in public documentation. Contact Delinea support for tenant-specific limits. HTTP 429 responses are returned when throttled.
• Pagination method: offset
• Default page size: 25
• Max page size: 100
• Pagination pointer: skip / take (REST API); startIndex / count (SCIM)

• Webhooks available: No
• Webhook notes: Delinea Platform does not expose a general-purpose outbound webhook system for user lifecycle events in publicly available documentation. Event-driven integrations are handled via SCIM provisioning from the IdP side or via Delinea's internal workflow/automation engine.
• Alternative event strategy: Use SCIM provisioning from Okta or Entra ID to push user lifecycle events into Delinea. For audit/event consumption, use the Delinea Platform audit log REST API endpoints or syslog/SIEM integration.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://.delinea.app/scim/v2

• Supported operations: GET /Users (list), GET /Users/{id}, POST /Users (create), PUT /Users/{id} (replace), PATCH /Users/{id} (update), DELETE /Users/{id}, GET /Groups (list), GET /Groups/{id}, POST /Groups (create), PATCH /Groups/{id} (add/remove members), DELETE /Groups/{id}, GET /ServiceProviderConfig, GET /Schemas

Limitations:

• SCIM requires SSO (SAML or OIDC) to be configured and active on the tenant before SCIM provisioning can be enabled.
• SCIM Bearer token is a static long-lived token; rotation requires manual regeneration in the admin console.
• Enterprise plan required; not available on Essentials or Standard tiers.
• PAM-specific attributes (vault access, secret permissions) are not fully manageable via standard SCIM attributes; use REST API or Delinea-specific SCIM extensions.
• Group membership changes via SCIM affect Delinea platform groups but may require additional configuration to propagate to PAM role assignments.
• Delinea Platform (cloud) and Secret Server (on-premise) have separate SCIM implementations; endpoint paths and token management differ.

The three highest-value automation scenarios against Delinea's API are SCIM-based provisioning from Okta or Entra ID, REST API-based deactivation for offboarding, and paginated user audits for identity graph reconciliation.

For SCIM provisioning: SSO must be active before SCIM can be enabled. The IdP must send externalId on every SCIM operation - missing externalId on subsequent PATCH/PUT calls is a documented cause of duplicate user creation. SCIM group membership changes propagate to Delinea platform groups but do not automatically map to PAM role assignments; a separate role-group binding must be configured within Delinea.

For REST API deactivation: set active=false via PATCH /api/v1/users/{id} using the platform UUID (not userName) as the path parameter. This disables login immediately but does not terminate active vault sessions or open checkouts - session cleanup is asynchronous and must be monitored separately via the sessions API.

For bulk audits: paginate with skip/take in increments of 100, check the total field in the first response to calculate required iterations, then filter client-side for active=true. Server-side filtering on active status is not guaranteed across all platform versions.

Provision a new employee via Okta SCIM

1. Ensure Enterprise plan is active and SSO (SAML/OIDC) is configured between Okta and Delinea Platform.
2. In Delinea Platform Admin > Integrations > SCIM, generate a SCIM Bearer token.
3. In Okta, add the Delinea SCIM application, set the SCIM base URL to https://.delinea.app/scim/v2, and paste the Bearer token.
4. Assign the user to the Okta application; Okta sends POST /scim/v2/Users with userName, name, emails, and externalId.
5. Delinea creates the user account and returns HTTP 201 with the new user id.
6. Optionally, assign the user to an Okta group mapped to a Delinea group to trigger PATCH /scim/v2/Groups/{id} for role-based access.

Watch out for: SSO must be active before SCIM provisioning works. The SCIM token is static and must be rotated manually if compromised.

Deactivate a departed employee via REST API

1. Obtain an OAuth 2.0 access_token via POST to /identity/connect/token with client_credentials grant.
2. Look up the user's platform UUID: GET /api/v1/users?filter=userName eq 'jdoe@example.com'.
3. Disable the account: PATCH /api/v1/users/{id} with body {"active": false}.
4. Verify the response confirms active=false.
5. Optionally, audit open PAM sessions via the sessions API and terminate any active checkouts.

Watch out for: Setting active=false disables login but does not immediately terminate active vault sessions. Monitor session endpoints separately.

Bulk list and audit all active users

1. Obtain an OAuth 2.0 access_token.
2. GET /api/v1/users?skip=0&take=100 to retrieve the first page.
3. Check the total field in the response; if total > 100, iterate with skip=100, skip=200, etc. until all pages are retrieved.
4. Filter results client-side for active=true users.
5. Cross-reference with your IdP's user list to identify orphaned accounts (present in Delinea but not in IdP).

Watch out for: Maximum take is 100 per request. Large tenants require multiple paginated calls. No server-side filter for active status is guaranteed across all platform versions.

The most common integration failure mode is treating Delinea Platform and Secret Server (on-premise) as the same API surface. They are separate products with different base URLs, different token management flows, and different SCIM implementations. Code written against one will not work against the other without modification.

The second trap is the SCIM token's static nature. Unlike the OAuth access token, the SCIM Bearer token does not expire on a schedule - it is long-lived and must be manually rotated in the admin console if compromised. There is no programmatic rotation endpoint documented in public references.

Rate limits are not publicly documented for any plan tier. HTTP 429 is returned when throttled, but no Retry-After header is confirmed in public documentation. Implement exponential backoff unconditionally.

Finally, deactivating a user via SCIM (active=false) is not equivalent to full offboarding in a PAM context: vault session cleanup is asynchronous, and PAM-specific attributes such as vault access grants and secret permissions are not fully manageable through standard SCIM attributes - those require REST API calls or Delinea-specific SCIM extensions.