Skip to main content
Every /v1 list endpoint returns the same envelope and paginates the same way: token-based, forward-only.

The list envelope

string
Always "list".
array
The page of resources, in a stable, deterministic order.
string | null
Pass this as page_token on the next request to fetch the following page. null when there are no more results.
boolean
Whether more results exist beyond this page.

Request parameters

integer
default:"25"
Page size. An integer between 1 and 500. Values outside that range return a 400 with code invalid_request.
string
The next_page_token from the previous response. Omit it for the first page.
There are no offset parameters, no previous-page traversal, and no exact total counts. To count a collection, walk it.
Exception: GET /v1/cohorts/{id}/members returns at most 50 rows per page even when you request a higher limit. has_more and next_page_token still reflect the true remainder of the cohort.
Authenticate with either Basic credential shape — see Quickstart (apikey:secret or secret:). Set BASE to the organization’s regional host — see Regions.

Walking a list

Load LIVING_SECURITY_API_KEY from your secret manager as in the quickstart. This example needs entity:read; the key used for the first-request guide may need that additional grant. Install requests for Python or jq for the shell example. Both examples pin a version, keep filters unchanged, and reject redirects. They stop on errors and after 1,000 pages rather than reporting a partial walk as complete. Python’s read timeout bounds inactivity, not the total job duration; impose a job deadline in your integration. Request pages until next_page_token is null. Prefer limit=500 for bulk reads so you cover the collection in fewer requests — see rate limits.

Keep filters stable while paginating

Page tokens are opaque, signed cursors. Each token is bound to the organization, the authenticated service account, the contract version, and the exact filter set of the request that produced it. Changing any of those mid-walk — for example, adding a type filter on page two — returns a 400 with code invalid_request on the page_token parameter:
400 Invalid request
To change filters, start a fresh walk from the first page.
Treat page_token as an opaque string: pass it back exactly as received. Do not decode, store long-term, or construct tokens — their internal format can change at any time without notice.
List endpoints reject query parameters they do not support with a 400 invalid_request naming the parameter. Check each endpoint’s reference for its supported filters.

Handle an interrupted or changing collection

These examples do not automatically retry errors. For 429, honor Retry-After and follow the bounded retry guidance. Keep the same region, service account, version, filters and last successfully processed page token when retrying a read. Changing credentials does not grant access: each request still checks current permissions. A multi-page read is not a snapshot of the collection. Rows can change while you traverse it. Process resources by their stable id and make downstream writes idempotent; a restart can return a row again. If a token is rejected, inspect the page_token error and correct the request before restarting from page one. Do not silently discard previously processed data or mark an interrupted export complete. For exact reporting totals, use the appropriate reporting resource instead of treating a live list traversal as a snapshot.