Keeper User Management API Guide

Auth method: Bearer token (SCIM provisioning token generated in Admin Console). Keeper Commander CLI uses device-level authentication with master password or SSO session.

Setup steps

1. Log in to the Keeper Admin Console at https://keepersecurity.com/console.
2. Navigate to Admin > Provisioning and select or create a SCIM provisioning method.
3. Generate a SCIM Bearer Token from the provisioning configuration page.
4. Store the token securely; it is shown only once and used as the Authorization Bearer header for all SCIM requests.
5. For Commander SDK/CLI: install via pip (pip install keepercommander), configure config.json with Keeper credentials or SSO device token, and authenticate interactively or via environment variables.

Required scopes

List Users

• Method: GET
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users
• Watch out for: The node_id in the URL path is the Keeper enterprise node ID, not a generic tenant ID. Retrieve it from the Admin Console provisioning settings.

Request example

GET /api/rest/scim/v2/123456/Users?startIndex=1&count=100
Authorization: Bearer <scim_token>

Response example

{"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],"totalResults":42,"startIndex":1,"itemsPerPage":100,"Resources":[{"id":"uid1","userName":"alice@example.com","active":true}]}

Get User

• Method: GET
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users/{id}
• Watch out for: Returns 404 if the user exists in Keeper but was not provisioned through this SCIM node.

Request example

GET /api/rest/scim/v2/123456/Users/uid1
Authorization: Bearer <scim_token>

Response example

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"id":"uid1","userName":"alice@example.com","name":{"givenName":"Alice","familyName":"Smith"},"active":true}

Create User

• Method: POST
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users
• Watch out for: Creating a user sends an invitation email. The user must accept and complete vault setup before SSO login is available.

Request example

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"bob@example.com","name":{"givenName":"Bob","familyName":"Jones"},"active":true}

Response example

{"id":"uid2","userName":"bob@example.com","active":true,"meta":{"resourceType":"User","location":"/scim/v2/123456/Users/uid2"}}

Update User partial

• Method: PATCH
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users/{id}
• Watch out for: Setting active=false locks the user but does not delete vault data. A separate DELETE is required to fully remove the user.

Request example

{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"replace","path":"active","value":false}]}

Response example

{"id":"uid2","userName":"bob@example.com","active":false}

Update User full replace

• Method: PUT
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users/{id}
• Watch out for: PUT replaces the full user resource. Omitting optional fields may clear them. Prefer PATCH for partial updates.

Request example

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"bob@example.com","active":false}

Response example

{"id":"uid2","userName":"bob@example.com","active":false}

Delete User

• Method: DELETE
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Users/{id}
• Watch out for: Deletion is irreversible. Vault data handling depends on enterprise transfer policy configured in the Admin Console before deletion.

Request example

DELETE /api/rest/scim/v2/123456/Users/uid2
Authorization: Bearer <scim_token>

Response example

HTTP 204 No Content

List Groups

• Method: GET
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Groups
• Watch out for: Keeper maps SCIM Groups to Keeper Teams, not to Keeper Roles. Role assignment must be done separately in Admin Console or via Commander.

Request example

GET /api/rest/scim/v2/123456/Groups?startIndex=1&count=100
Authorization: Bearer <scim_token>

Response example

{"totalResults":5,"Resources":[{"id":"gid1","displayName":"Engineering","members":[{"value":"uid1"}]}]}

Create Group

• Method: POST
• URL: https://keepersecurity.com/api/rest/scim/v2/{node_id}/Groups
• Watch out for: Group displayName must be unique within the node. Duplicate names return 409 Conflict.

Request example

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:Group"],"displayName":"Finance","members":[{"value":"uid1"}]}

Response example

{"id":"gid2","displayName":"Finance","members":[{"value":"uid1"}]}

• Rate limits: Keeper does not publish explicit numeric rate limits in official documentation for SCIM or REST endpoints.
• Rate-limit headers: No
• Retry-After header: No
• Rate-limit notes: No official rate limit figures are published. Keeper recommends using IdP-native throttling (e.g., Okta, Azure AD) to avoid overloading the endpoint.
• Pagination method: offset
• Default page size: 100
• Max page size: 1000
• Pagination pointer: startIndex and count (SCIM standard parameters)

• Webhooks available: No
• Webhook notes: Keeper does not offer outbound webhooks for user lifecycle events in official documentation. Event-driven workflows must be initiated from the IdP side.
• Alternative event strategy: Use IdP-native event hooks (Okta, Azure AD) to trigger SCIM provisioning actions to Keeper, or use Keeper Commander CLI scripted on a schedule for sync tasks.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://keepersecurity.com/api/rest/scim/v2/{node_id}

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

Limitations:

• SCIM requires Enterprise plan; not available on Business or Business Starter.
• SSO (Keeper SSO Connect) must be configured before SCIM provisioning is enabled.
• The node_id path parameter is specific to the enterprise node; multi-node enterprises require separate SCIM tokens per node.
• Vault data is not deleted automatically on SCIM DELETE; vault transfer policy must be pre-configured in Admin Console.
• SCIM Groups map to Keeper Teams, not Keeper Roles; role assignment requires Admin Console or Commander.
• Bulk operations endpoint is not supported.
• Password and credential fields are not accessible via SCIM due to zero-knowledge architecture.

The canonical provisioning flow via Okta requires SSO Connect active, a SCIM Bearer Token scoped to the target node, and the Keeper SCIM app configured in Okta with the node-specific base URL.

A POST /Users from Okta creates the Keeper account and triggers an invitation email; the user must complete vault setup before SSO login is available - this step cannot be skipped even with SSO enforced.

For offboarding, the IdP sends PATCH /Users/{id} with active=false to lock the account; a subsequent DELETE /Users/{id} is required to fully remove the user and free the seat. These are two distinct, non-atomic operations.

Vault data recovery on deletion depends entirely on whether an Account Transfer Policy was pre-configured in Admin Console before the user's initial invite acceptance - there is no API mechanism to retroactively enable this.

SCIM Groups map to Keeper Teams (shared folder access), not to Keeper Roles (admin permissions); role assignment has no SCIM equivalent and must be handled via Admin Console or Commander.

Provision a new employee via Okta SCIM

1. Ensure Keeper SSO Connect is configured with Okta as the IdP.
2. In Keeper Admin Console, navigate to Admin > Provisioning > Add Method > SCIM and generate a Bearer Token.
3. In Okta, configure the Keeper SCIM app with base URL https://keepersecurity.com/api/rest/scim/v2/{node_id} and the Bearer Token.
4. Assign the new employee to the Keeper app in Okta; Okta sends POST /Users to Keeper SCIM.
5. Keeper creates the user account and sends an invitation email; user completes vault setup.
6. Assign the user to an Okta group mapped to a Keeper Team; Okta sends PATCH /Groups to add the member.

Watch out for: The invitation email is always sent even with SSO configured; the user must click it and complete initial vault setup before SSO login is available.

Offboard a departing employee

1. Pre-configure a vault transfer policy in Keeper Admin Console under Admin > Roles > Enforcement Policies > Account Transfer.
2. In the IdP, deactivate or remove the user from the Keeper application.
3. IdP sends PATCH /Users/{id} with active=false; Keeper locks the user account immediately.
4. Optionally send DELETE /Users/{id} to remove the user from the enterprise node.
5. The designated admin initiates vault transfer from the Admin Console to recover shared credentials.

Watch out for: If vault transfer policy is not configured before deletion, vault data may be unrecoverable due to Keeper zero-knowledge encryption.

Bulk user management via Keeper Commander CLI

1. Install Keeper Commander: pip install keepercommander.
2. Create a config.json with Keeper admin credentials or SSO device token.
3. Run keeper shell to enter interactive mode, or use keeper --batch-mode for scripted operations.
4. Use enterprise-user list to enumerate users, enterprise-user invite to create users, and enterprise-user lock or enterprise-user delete for lifecycle management.
5. Use enterprise-team add-user to assign users to teams (equivalent to SCIM Group membership).

Watch out for: Commander requires admin-level Keeper credentials and device approval; it is not token-based like SCIM and is not suitable for IdP-driven automated provisioning.

The primary integration trap is the node_id path parameter: it is not a standard SCIM tenant identifier and is invisible to IdP SCIM app templates that assume a flat base URL. Misconfiguring it produces 404s that are easy to misattribute to auth failures.

The second trap is the active/delete split: setting active=false locks the user but preserves vault data and the license seat; DELETE is irreversible and vault data is unrecoverable if transfer policy was not pre-configured. These two operations must be sequenced deliberately, not treated as equivalent offboarding actions.

For teams building an identity graph across their SaaS stack, Keeper's zero-knowledge model means no password or vault content fields are accessible or settable via any API - the identity graph can track user existence, group membership, and active status, but vault contents are architecturally opaque.

Webhooks are not available; event-driven workflows must originate from the IdP side, making Keeper a passive provisioning target rather than an event source.