Skip to main content

About the Events API beta

The 1Password Events API v3 (version 3) beta is a REST-style HTTP API that follows the OpenAPI 3.0 specification. All requests are made over HTTPS and return JSON responses.

The beta introduces a new v3 versioned endpoint:

  • GET /api/v3/auditevents

This endpoint returns audit events for actions performed by team members in a 1Password account. Each event describes:

  • Who performed the action (the actor).
  • What was affected (one or more target entities).
  • Where and how the action occurred (context about the account, location, client, device, and session).

The beta API can be used alongside the existing Events API. The v1 and v2 endpoints for audit events, item usages, and sign-in attempts remain available.

Request methods​

The beta API currently supports a single HTTP method (GET) to retrieve audit events and uses query parameters for pagination and time filters.

The /api/v3/auditevents beta endpoint uses GET with query parameters for pagination and time filters.

info

The v1 and v2 API endpoints continue to use POST requests with a cursor object in the request body.

Servers and URLs​

The v3 beta endpoint is currently hosted on the same Events API servers as the production API. Your base URL depends on the region where your 1Password account is hosted:

If your account is hosted on:Your base URL is:
1password.comhttps://events.1password.com
ent.1password.comhttps://events.ent.1password.com
1password.cahttps://events.1password.ca
1password.euhttps://events.1password.eu

To call the beta endpoint, append the v3 path to your base URL:

All requests must be made over HTTPS.

info

It's possible these servers could change during the beta or when the v3 endpoint moves to production. You can use the Events API beta roadmap and changelog to track changes.

Endpoints​

The v3 beta API uses the following endpoint:

Item usage and sign-in attempt events remain available through the existing v1 and v2 endpoints.

Authorization​

All calls to the v3 beta endpoint must be authorized with a valid JWT-encoded bearer token in the Authorization header. The token must be scoped to include audit events.

Request headers​

Requests to the beta endpoint require the Authorization header:

If your bearer token is missing, malformed, or invalid, the API will return a 401 Unauthorized response.

Pagination​

The beta API uses cursor-based pagination passed in the query string.

Query parameters​

The v3 auditevents endpoint accepts the following optional query parameters:

  • page_size: The maximum number of events to return in a single response.
  • start_time: The earliest timestamp to include in the result set (inclusive).
  • end_time: The latest timestamp to include in the result set (inclusive).
  • next_page_token: An opaque token that identifies the next page of results to retrieve.
info

Data collection for the /api/v3/auditevents beta endpoint started December 1, 2025. To access event data prior to that date, you'll need to use the /api/v2/auditevents production endpoint.

Response metadata​

Every 200 successful response includes a meta object with pagination metadata:

  • next_page_token: A token you can pass to the next request to retrieve the next page of results.
  • has_more: A boolean value that indicates whether additional pages are available (true or false).

When has_more is true, you can continue making requests with next_page_token until there are no more events, indicated by "has_more": false.

Pagination workflow​

The following example shows a typical pagination workflow:

  1. Initial request: Make A GET call to /api/v3/auditevents with any combination of page_size, start_time, and end_time parameters you need. Note that data collection for this endpoint started December 1, 2025.

  2. Check the response: Process the audit_events and check the has_more and next_page_token metadata.

  3. Subsequent requests: If has_more is true, call the endpoint again. For example:

    Repeat until has_more is false and you’ve retrieved all events for the requested interval.

    Make sure not to use the start_time and end_time query parameters with the next_page_token query parameter. Doing so will result in a 400 bad request error.

Rate limits​

Requests to the beta endpoint are rate limited to:

  • 600 requests per minute
  • 30,000 requests per hour

The API uses standard HTTP headers to communicate your current rate limit window and remaining quota. Responses from GET /api/v3/auditevents may include the following headers:

  • RateLimit-Limit: The total number of requests allowed for the current time window.
  • RateLimit-Remaining: How many requests you can still make in the current window.
  • RateLimit-Reset: The Unix timestamp (in seconds) that indicates when the current rate limit window will reset.

If you exceed the allowed rate, the API returns a 429 Too Many Requests response. The 429 response includes the following header:

Retry-After: Indicates how many seconds to wait before making another request.

When you receive 429 Too Many Requests, you should:

  1. Stop sending additional requests to the endpoint.
  2. Wait for the number of seconds specified in the Retry-After header.
  3. Resume requests, ideally with backoff and retry logic in your client.

Was this page helpful?