Skip to main content
All list endpoints in the Deck API use cursor-based pagination. Each response includes a data array, a has_more flag, and a next_cursor value you pass on subsequent requests to fetch the next page.

Request parameters

Response format

Every list response has the same shape:
array
Array of resource objects for the current page.
boolean
true if there are more results beyond this page. false on the last page.
string or null
An opaque string to pass as the cursor query parameter on the next request. null when there are no more pages.
string
Unique identifier for the API request.

Fetching the next page

Pass next_cursor from the previous response as the cursor query parameter:
Continue until has_more is false.

Paginating through all results

Filtering and sorting

List endpoints may accept additional query parameters for filtering. Filters are applied server-side before pagination, so the limit applies to filtered results.
Results are returned in reverse chronological order (newest first) by default.

Cursors are opaque

Cursor values are opaque strings. Do not parse, construct, or store them long-term. They encode internal position state and may change format between API versions.
  • Pass them exactly as received from the API.
  • Do not reuse cursors across different endpoints or filter combinations.
  • If a cursor becomes invalid, the API returns a 400 error with cursor_invalid. Start from the first page.

Stable ordering

Deck guarantees stable ordering within a paginated sequence. If no records are created or deleted between requests, every record appears exactly once across all pages. Records created after you begin paginating may or may not appear depending on their position in the sort order.