Pagination

Cursor-based pagination, newest first.

List endpoints return up to 100 items per call wrapped in a list envelope. Walk through history with opaque cursors — no skip/offset to drift.

The list envelope

200 OK

{
  "object": "list",
  "data": [ /* up to <limit> resources */ ],
  "has_more": true,
  "next_cursor": "v1:5a1b2c3d4e5f6a7b8c9d0e1f:1716657480000",
  "previous_cursor": null,
  "url": "/v1/orders"
}

Parameters

Param	Default	Notes
`limit`	10	Max 100. Larger requests are capped, not rejected.
`starting_after`	—	Cursor from a previous response. Fetches items older than the boundary.
`ending_before`	—	Cursor from a previous response. Fetches items newer than the boundary. Mutually exclusive with starting_after.

Walking the full list

Loop while has_more is true, passing each next_cursor back as starting_after:

# First page (newest first)
curl 'https://api.tablezio.com/v1/orders?limit=10' \
  -H 'X-API-Key: tbz_…'

# Next page — pass the previous response's next_cursor
curl 'https://api.tablezio.com/v1/orders?limit=10&starting_after=v1:5a1b2c…:1716657480000' \
  -H 'X-API-Key: tbz_…'

Filters compose with pagination

Most list endpoints accept resource-specific filters (e.g. status, type, created.gte). These compose with the cursor — your cursor is still valid as you change filters, because cursors are opaque IDs not offsets.