LastPass User Management API Guide

Auth method: API key (provisioning hash) passed as a field in the JSON POST body; no OAuth 2.0

Setup steps

1. Log in to the LastPass Admin Console as an admin.
2. Navigate to Advanced Options > Enterprise API.
3. Generate or copy the Provisioning Hash (API key) displayed there.
4. Include the provisioning hash as the 'hash' field and your account's company ID as 'cid' in every API request body.

Create user

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: All operations use the same POST endpoint; the 'cmd' field determines the action. 'batchadd' creates users and is idempotent if the user already exists.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "batchadd",
  "data": [{"username": "jane@example.com", "firstname": "Jane", "lastname": "Doe"}]
}

Response example

{
  "status": "OK",
  "results": [{"status": "OK", "username": "jane@example.com"}]
}

Update user

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: User updates also use 'batchadd'; only supplied fields are updated. Omitted fields are not cleared.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "batchadd",
  "data": [{"username": "jane@example.com", "department": "Engineering"}]
}

Response example

{
  "status": "OK",
  "results": [{"status": "OK", "username": "jane@example.com"}]
}

Delete user

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: 'deleteaction' controls behavior: 0=remove from company, 1=delete account + data, 2=delete account but transfer vault data. Irreversible for actions 1 and 2.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "deluser",
  "data": {"username": "jane@example.com", "deleteaction": 0}
}

Response example

{
  "status": "OK"
}

Disable user

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: Disabled users cannot log in but their vault data is retained. Use 'enableuser' cmd to re-enable.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "disableuser",
  "data": {"username": "jane@example.com"}
}

Response example

{
  "status": "OK"
}

Get user data / list users

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: Omitting 'username' from data returns all users in the account. Large accounts may return very large payloads; no pagination is supported.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "getuserdata",
  "data": {"username": "jane@example.com"}
}

Response example

{
  "Users": {
    "jane@example.com": {
      "username": "jane@example.com",
      "firstname": "Jane",
      "lastname": "Doe",
      "admin": 0,
      "disabled": 0
    }
  }
}

Add user to group

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: Groups must already exist in LastPass. Specifying a non-existent group name may silently fail or create the group depending on account settings.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "batchadd",
  "data": [{"username": "jane@example.com", "groupsin": ["Engineering"]}]
}

Response example

{
  "status": "OK",
  "results": [{"status": "OK", "username": "jane@example.com"}]
}

Reset master password

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: Sends a password reset email to the user. Not applicable for federated (SSO) users whose authentication is managed by the IdP.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "resetpassword",
  "data": {"username": "jane@example.com"}
}

Response example

{
  "status": "OK"
}

Get audit log / reporting

• Method: POST
• URL: https://lastpass.com/enterpriseapi.php
• Watch out for: Reporting endpoint supports date-range filtering and a 'pagesize' parameter, making it one of the few endpoints with partial pagination support.

Request example

{
  "cid": "12345",
  "provhash": "<provisioning_hash>",
  "cmd": "reporting",
  "data": {"from": "2024-01-01", "to": "2024-01-31", "pagesize": 100}
}

Response example

{
  "status": "OK",
  "data": [{"Time": "2024-01-15 10:22:00", "Username": "jane@example.com", "Action": "User Login"}]
}

• Rate limits: LastPass does not publish explicit rate limit tiers or numeric thresholds in official documentation. Practical guidance recommends avoiding bulk rapid requests.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No documented rate limit headers or retry-after headers. Contact LastPass support for enterprise-level throughput guidance.

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: LastPass does not offer native outbound webhooks for user or vault events as of the current documentation.

• Alternative event strategy: Poll the 'reporting' API command on a schedule to detect user activity and provisioning events.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Business

• Endpoint: https://lastpass.com/scim/v2

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

Limitations:

• Requires Business or Enterprise plan.
• SSO (federated login) must be configured as a prerequisite for SCIM provisioning.
• SCIM token is generated from the LastPass Admin Console under Advanced > SCIM.
• Supported IdPs with native connectors: Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin.
• SCIM provisioning does not sync vault items or shared folders; only user identity and group membership.
• Deprovisioning via SCIM disables the user; full vault deletion requires manual action or the provisioning API 'deluser' command.

Three integration patterns cover the majority of production use cases. First, direct provisioning via the Provisioning API: POST cmd='batchadd' with username, firstname, lastname, and groupsin to create or update a user; 'batchadd' is idempotent if the user already exists.

Second, deprovisioning: POST cmd='disableuser' immediately to block access, then POST cmd='deluser' with deleteaction=0 (remove from company), 1 (delete account and all vault data), or 2 (delete account, transfer vault data)-actions 1 and 2 are irreversible and permanently destroy vault data.

Third, IdP-driven SCIM sync (e. g.

, Okta): generate a SCIM bearer token from Admin Console > Advanced > SCIM, configure the LastPass app in Okta with the SCIM base URL and token, then enable Push Users and Push Groups.

Rotating the SCIM token in LastPass immediately breaks the Okta connection; always update the token in Okta before rotating in production. For federated (SSO) users, never set a master password via the API-authentication state is owned by the IdP.

Onboard a new employee via Provisioning API

1. POST to enterpriseapi.php with cmd='batchadd', supplying username (email), firstname, lastname, and groupsin array.
2. Verify response body contains status='OK' for the user entry.
3. Optionally POST cmd='resetpassword' to trigger a welcome/setup email if not using federated login.

Watch out for: If federated login (SSO) is active, do not set a password via the API-authentication is controlled by the IdP and setting a master password may conflict with federated account state.

Deprovision a departing employee

1. POST cmd='disableuser' immediately to block access while deciding on data disposition.
2. Coordinate with IT/security on vault data transfer requirements.
3. POST cmd='deluser' with deleteaction=0 to remove from company without destroying vault, or deleteaction=1 to permanently delete all data.

Watch out for: deleteaction=1 and deleteaction=2 are irreversible. Confirm data transfer or backup requirements before executing. SCIM deprovisioning only disables the user; it does not delete vault data.

Sync users from Okta via SCIM

1. Ensure LastPass Business plan is active and SSO/federated login is configured.
2. In LastPass Admin Console, navigate to Advanced > SCIM and generate a SCIM bearer token.
3. In Okta, add the LastPass application from the Okta Integration Network and configure SCIM provisioning with the LastPass SCIM base URL and bearer token.
4. Enable 'Push Users' and 'Push Groups' in Okta provisioning settings.
5. Assign users/groups in Okta; Okta will POST to LastPass SCIM /Users to create accounts automatically.

Watch out for: SCIM token rotation in LastPass invalidates the existing Okta connection immediately; update the token in Okta's provisioning settings before rotating in production.

The single-endpoint, cmd-driven design means there is no idiomatic REST structure to rely on, and no official SDK exists-every integration is built against raw HTTP. Rate limits are undocumented; LastPass publishes no numeric thresholds, no rate-limit headers, and no Retry-After headers, making backoff logic a best-guess exercise.

The 'getuserdata' list endpoint has no pagination, so full directory syncs for large accounts must handle arbitrarily large response payloads in a single call.

SCIM provisioning requires SSO/federated login to be active first-enabling SCIM without SSO is not supported, which creates a sequencing dependency that can block identity graph population if SSO is not yet rolled out.

Group names in the Provisioning API are case-sensitive and must match the Admin Console exactly; a mismatch may silently fail or create a duplicate group depending on account configuration.