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.