GET /v1/payment-intents, GET /v1/reconciliation-cases, GET /v1/api-keys, GET /v1/audit-events, GET /v1/outbound-webhook-events, and similar — use offset-based pagination with two query parameters.
Query parameters
integer
Number of items to return. Minimum
1, maximum 100. Default varies by endpoint — most list endpoints default to 25; GET /v1/audit-events and GET /v1/api-keys default to 50. Check the endpoint’s reference page for its exact default.integer
default:"0"
Number of items to skip from the start of the result set. Minimum
0.Response shape
Every paginated list endpoint returns the same envelope:array
required
The page of results. Each item’s shape depends on the endpoint (e.g. a
PaymentIntent summary, a ReconciliationCaseSummary, an ApiKeySnapshot).integer
required
Total number of items matching the request’s filters, across all pages — not just the current page.
integer
required
Echoes the
limit used for this request (after defaulting).integer
required
Echoes the
offset used for this request.Traversing all pages
Incrementoffset by limit until offset >= total:
Filtering combined with pagination
Most list endpoints accept additional filter query parameters alongsidelimit and offset — for example GET /v1/payment-intents accepts status and externalReference, and GET /v1/reconciliation-cases accepts status, reconciliationStatus, and externalReference. total reflects the count after filters are applied, so traversal logic works the same way whether or not you’re filtering.
Sending an out-of-range
limit (e.g. above 100) or a negative offset returns 400 invalid_request with an issues array — see Errors.Next steps
- Errors — validation error shape for out-of-range pagination parameters.
- Rate limits — limits that apply while paging through large result sets.
- Reconciliation cases: list reconciliation cases and Payment intents: list payment intents for concrete examples.