Pagination and filtering

Page through RestoreTrust list endpoints with stable cursors, sorting, and resource-specific filters.

List endpoints use POST /v1/{resource}/list. Pagination, sorting, project scope, and filters are sent in the JSON body.

Request a page

json

{  "project_id": "65f0c7a9a7d6b4e2c1234567",  "sort": "created-desc",  "pagination": {    "limit": 25  },  "filters": {    "status": "active"  }}

pagination.limitintegeroptional

Number of rows to return. Defaults to 25; minimum 1, maximum 200.

sort"created-asc" | "created-desc"optional

Sorts by creation time. Defaults to created-desc.

filtersobjectoptional

Resource-specific filters. Unknown filter keys return 400.

Some session-only project lists also support updated-asc and updated-desc. Follow the schema on the generated endpoint page.

Continue from a cursor

When has_more is true, copy both values from next_cursor into the next request:

json

{  "project_id": "65f0c7a9a7d6b4e2c1234567",  "sort": "created-desc",  "pagination": {    "limit": 25,    "after_id": "65f0d012a7d6b4e2c2468101",    "after_value": "2026-09-30T13:45:12Z"  },  "filters": {    "status": "active"  }}

Keep the query stable

Reuse the same sort, filters, and project for every page. Supply after_id and after_value together; sending only one returns 400, as does an after_value without an explicit offset or Z.

Treat cursor values as opaque. Stop when has_more is false; next_cursor is then absent.

For counts across the project, use the check summary or schedule summary. Counting one list page does not give the total. Summary endpoints have their own request fields and do not inherit list filters.

Available filters

Each resource page summarizes useful filters, while the generated operation page is the source of truth:

Pagination and filtering

Request a page

Continue from a cursor

Available filters

Related topics

Request a page

Continue from a cursor

Available filters

Related topics