The catalog list endpoints — /v1/products, /v1/orders, /v1/customers, /v1/customers/{id}/orders and /v1/landing-pages — use cursor pagination. Offsets are intentionally not supported.
Request:
GET /v1/products?limit=50&cursor=<opaque>
Response:
{ "data": {
"items": [...],
"next_cursor": "MTIz",
"has_more": true
} }
If has_more is false, you've drained the resource.
limit defaults to 50 and is clamped to 1–200: an out-of-range or non-numeric value is silently adjusted, not rejected. Pages walk newest-first, so the cursor points at the last item you received.
⚠️ Warning — A malformed cursor is silently ignored
A truncated or corrupted cursor does not return bad_request — it is dropped and the list restarts from the newest record. Treat the token as fully opaque, pass it back byte-for-byte, and stop when has_more is false; a client that mangles the token will otherwise re-fetch page 1 forever.
Endpoints that are not cursor-paginated
GET /v1/keysandGET /v1/webhooksreturn the completeitemsarray with nonext_cursor/has_more.GET /v1/usage/historyis range-based viafrom/to(90 days maximum) and returnsrows.