1Password User Management API Guide

Auth method: Bearer token. The SCIM Bridge issues a bearer token paired with a scimsession file during setup. The bearer token is provided to the IdP; the scimsession file is mounted into the SCIM Bridge container via the OP_SESSION environment variable. The Events API uses a separate bearer token issued through 1Password.com > Integrations > Events Reporting.

Setup steps

1. Sign in to 1Password.com and navigate to Integrations > User Provisioning.
2. Select your identity provider and follow the setup wizard to generate a scimsession file and bearer token.
3. Deploy the 1Password SCIM Bridge container (1password/scim) on your own infrastructure (GCP, DigitalOcean, Azure Container Apps, Kubernetes, or custom).
4. Mount the scimsession file into the SCIM Bridge container via the OP_SESSION environment variable.
5. Provide the bearer token to your IdP as the API token / secret token for the SCIM integration.
6. Point your IdP's SCIM base URL to your deployed SCIM Bridge domain (e.g., https://scim.example.com/scim/v2).
7. For the Events API: go to Integrations > Events Reporting in 1Password.com and issue a separate bearer token scoped to the required features (auditevents, signinattempts, itemusages).

Required scopes

List Users

• Method: GET
• URL: https://<scim-bridge>/scim/v2/Users
• Watch out for: TotalResults was inaccurate in SCIM Bridge v2.9.0 (broke Okta imports); fixed in v2.9.1+. Always verify bridge version.

Request example

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

Response example

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

Get User

• Method: GET
• URL: https://<scim-bridge>/scim/v2/Users/{id}
• Watch out for: The id is 1Password's internal UUID, not the IdP's externalId. Use userName (email) to correlate with IdP records.

Request example

GET /scim/v2/Users/abc-uuid-123
Authorization: Bearer <token>

Response example

{
  "id": "abc-uuid-123",
  "userName": "user@example.com",
  "name": {"givenName": "Jane", "familyName": "Doe"},
  "active": true,
  "emails": [{"value": "user@example.com", "primary": true}]
}

Create User

• Method: POST
• URL: https://<scim-bridge>/scim/v2/Users
• Watch out for: User is created in 'Invited' state. SCIM Bridge auto-confirms the account within ~5 minutes after the user accepts the invitation email. Email domain must be in the account's allowed domains list.

Request example

POST /scim/v2/Users
Authorization: Bearer <token>
Content-Type: application/scim+json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jane@example.com",
  "name": {"givenName": "Jane", "familyName": "Doe"},
  "emails": [{"value": "jane@example.com", "primary": true}]
}

Response example

HTTP 201 Created
{
  "id": "new-uuid",
  "userName": "jane@example.com",
  "active": true
}

Update User (replace)

• Method: PUT
• URL: https://<scim-bridge>/scim/v2/Users/{id}
• Watch out for: Changing userName triggers a 1Password email-change confirmation flow - the change is not instant. Do not change email for suspended users; some IdPs don't sync email changes for suspended users, causing the bridge to treat them as new users on reactivation.

Request example

PUT /scim/v2/Users/abc-uuid-123
Authorization: Bearer <token>
Content-Type: application/scim+json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jane@example.com",
  "name": {"givenName": "Jane", "familyName": "Smith"},
  "active": true
}

Response example

HTTP 200 OK
{"id": "abc-uuid-123", "userName": "jane@example.com", "active": true}

Suspend / Deprovision User

• Method: PATCH
• URL: https://<scim-bridge>/scim/v2/Users/{id}
• Watch out for: Setting active=false suspends the user in 1Password but does NOT permanently delete the account. Permanent deletion must be done manually on 1Password.com.

Request example

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

Response example

HTTP 200 OK
{"id": "abc-uuid-123", "active": false}

List Groups

• Method: GET
• URL: https://<scim-bridge>/scim/v2/Groups
• Watch out for: Only groups explicitly selected as 'Managed Groups' in 1Password provisioning settings are synced. Nested groups are not fully supported.

Request example

GET /scim/v2/Groups?startIndex=1&count=50
Authorization: Bearer <token>

Response example

{
  "totalResults": 5,
  "Resources": [{"id": "grp-uuid", "displayName": "Engineering", "members": []}]
}

Get Audit Events (Events API v2)

• Method: POST
• URL: https://events.1password.com/api/v2/auditevents
• Watch out for: Requires a separate Events API bearer token (not the SCIM bearer token) scoped with 'auditevents'. Events API base URL is region-specific: events.1password.com (US), events.1password.ca (CA), events.1password.eu (EU).

Request example

POST /api/v2/auditevents
Authorization: Bearer <events-token>
Content-Type: application/json
{
  "limit": 100,
  "start_time": "2024-01-01T00:00:00Z"
}

Response example

{
  "cursor": "opaque-cursor-string",
  "has_more": true,
  "items": [{"uuid": "evt-uuid", "timestamp": "2024-01-01T12:00:00Z", "action": "update", "object_type": "user"}]
}

Get Audit Events (Events API v3 beta)

• Method: GET
• URL: https://events.1password.com/api/v3/auditevents
• Watch out for: Beta only - not recommended for production. Data only available from December 1, 2025 onward. Uses next_page_token query param for pagination, not cursor in POST body.

Request example

GET /api/v3/auditevents?page_size=100&start_time=2026-01-01T00:00:00Z
Authorization: Bearer <events-token>

Response example

{
  "audit_events": [{"uuid": "evt-uuid", "timestamp": "2026-01-02T10:00:00Z"}],
  "meta": {"next_page_token": "token-abc", "has_more": true}
}

• Rate limits: Two independent rate-limit systems apply: (1) Service Accounts have hourly and daily limits by plan tier. (2) The Events API has its own per-minute and per-hour limits. The SCIM Bridge returns HTTP 429 when rate-limited by 1Password servers.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: SCIM Bridge returns HTTP 429 when rate-limited by 1Password servers. Service account limits and Events API limits are independent systems. Events API v3 beta returns RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers; 429 responses include Retry-After. Implement exponential backoff on 429.
• Pagination method: cursor
• Default page size: 100
• Max page size: 1000
• Pagination pointer: cursor (Events API v2 POST body); next_page_token (Events API v3 beta GET query param); startIndex + count (SCIM endpoints, RFC 7644 offset pagination)

• Webhooks available: No
• Webhook notes: 1Password does not offer outbound webhooks for user lifecycle events. The Events API is a polling-based REST API, not a push/webhook system.
• Alternative event strategy: Poll the Events API (POST /api/v2/auditevents, /api/v2/signinattempts, /api/v2/itemusages) on a schedule using the cursor for incremental fetches. A v3 beta GET-based endpoint with next_page_token pagination is available for audit events (data from Dec 1, 2025 onward). Many SIEMs have pre-built 1Password connectors.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Business ($7.99/user/month)

• Endpoint: https:///scim/v2

• Supported operations: Create user (POST /Users), Get user (GET /Users/{id}), List users (GET /Users), Update user attributes (PUT /Users/{id}), Patch user / suspend user (PATCH /Users/{id}), Create group (POST /Groups), Get group (GET /Groups/{id}), List groups (GET /Groups), Update group membership (PATCH /Groups/{id}), Delete group (DELETE /Groups/{id}), ServiceProviderConfig (GET /ServiceProviderConfig), Schemas (GET /Schemas), ResourceTypes (GET /ResourceTypes)

Limitations:

• Requires self-hosting the SCIM Bridge container (1password/scim) on your own infrastructure - GCP, DigitalOcean, Azure Container Apps, Kubernetes, or custom. 1Password does not host the bridge.
• Only one SCIM Bridge instance should run at a time; high-availability multi-instance deployments are not supported.
• SSO (Unlock with SSO via OIDC) is a separate integration from SCIM provisioning; they can be used together but must be configured independently.
• Nested groups are not fully supported.
• Deprovisioning suspends users in 1Password; permanent deletion requires manual action on 1Password.com.
• Email changes for suspended users can cause the bridge to treat the user as a new account on reactivation.
• Only groups explicitly selected as 'Managed Groups' in 1Password provisioning settings are synced.
• Guest users cannot be managed via automated provisioning.
• SCIM Bridge must be kept updated; deprecated versions stop syncing after notice period.
• Supported IdPs: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, Rippling.
• The deprecated OP_SCIMSESSION environment variable is no longer available; use OP_SESSION instead.

Three scenarios cover the majority of programmatic use cases.

First, provisioning via an IdP (Okta, Entra ID, Google Workspace, JumpCloud, OneLogin, Rippling): deploy the SCIM Bridge, configure the SCIM Base URL and bearer token in the IdP app, assign users or groups, and the IdP sends SCIM POST /Users to create accounts in 'Invited' state.

the bridge auto-confirms after the user accepts the invitation email. The user's email domain must be in 1Password's allowed domains list or provisioning fails silently from the IdP's perspective.

Second, deprovisioning: the IdP sends SCIM PATCH /Users/{id} with active=false, which suspends the user in 1Password but does not delete the account or vault data - permanent deletion requires a manual Owner action on 1password. com.

Do not change a suspended user's email in the IdP before deletion; the bridge may treat the reactivated user as a new account. Third, streaming audit events to a SIEM: issue a separate Events API bearer token scoped to auditevents, signinattempts, and/or itemusages; POST to the region-correct endpoint (events.

1password. com for US, events.

1password. ca for Canada, events.

1password. eu for EU) with a ResetCursor body; store and advance the cursor on each poll.

The Events API is polling-only - there are no outbound webhooks.

Provision a new employee via Okta

1. Deploy 1Password SCIM Bridge on your infrastructure and configure it with the scimsession file via OP_SESSION.
2. In Okta, add the 1Password Business app and configure the SCIM Base URL (your bridge URL) and API Token (bearer token).
3. Assign the new employee's Okta user or group to the 1Password Business app.
4. Okta sends a SCIM POST /Users request to the SCIM Bridge with the user's userName (email), givenName, familyName.
5. SCIM Bridge creates the user in 1Password in 'Invited' state and sends an invitation email.
6. SCIM Bridge auto-confirms the account within ~5 minutes after the user accepts the invitation.
7. Group memberships assigned in Okta are synced via SCIM PATCH /Groups operations.

Watch out for: The user's email domain must be in the 1Password account's allowed domains list or provisioning will fail with a clear error. Test with a single user before rolling out to all groups.

Deprovision a departing employee

1. In your IdP (e.g., Entra ID), disable the user or remove their assignment from the 1Password app.
2. IdP sends a SCIM PATCH /Users/{id} with active=false to the SCIM Bridge.
3. SCIM Bridge sets the user's status to 'Suspended' in 1Password, revoking access.
4. If permanent deletion is required, an admin must manually delete the account on 1Password.com.

Watch out for: Suspension does not delete the user or their vault data. Do not change the suspended user's email in the IdP before permanent deletion - it can cause the bridge to create a duplicate account on reactivation.

Stream audit events to a SIEM

1. In 1Password.com, go to Integrations > Events Reporting and create a new integration for your SIEM.
2. Issue a bearer token scoped to 'auditevents', 'signinattempts', and 'itemusages' as needed.
3. Determine your account's Events API region (e.g., events.1password.com for US).
4. Make a POST request to /api/v2/auditevents with a ResetCursor body to begin fetching from the start.
5. Store the returned cursor and use it in subsequent POST requests to fetch incremental events.
6. Schedule polling (e.g., every 5 minutes) using the cursor to avoid re-fetching events.

Watch out for: The Events API is polling-only - there are no webhooks. Stay within the 600 req/min and 30,000 req/hour rate limits. The v3 beta endpoint (GET /api/v3/auditevents) only has data from December 1, 2025 onward and is not recommended for production.

The self-hosted SCIM Bridge is the central operational trap. Only one bridge instance should run at a time; high-availability multi-instance deployments are not supported. The bridge must be kept updated - deprecated versions stop syncing after a 90-day notice window.

The bearer token and scimsession file are a paired credential set: the bearer token alone is insufficient, and the scimsession file must be present on the running container at all times.

The SCIM bearer token and the Events API bearer token are entirely separate credentials issued through different dashboard flows; conflating them is a common integration error.

Rate limits are also split across independent systems: Service Accounts on Business are capped at 10,000 requests/day per service account and 50,000/day per account, while the Events API allows 600 requests/minute and 30,000/hour - HTTP 429 responses from the bridge require exponential backoff.

Nested groups are not fully supported, guest users cannot be managed via SCIM at all, and only groups explicitly designated as 'Managed Groups' in provisioning settings are synced. The v3 Events API beta (GET-based, next_page_token pagination) only contains data from December 1, 2025 onward, making it unsuitable for historical backfills.