Les endpoints de liste du catalogue — /v1/products, /v1/orders, /v1/customers, /v1/customers/{id}/orders et /v1/landing-pages — utilisent la pagination par curseur. Les offsets ne sont volontairement pas supportés.
Requête :
GET /v1/products?limit=50&cursor=<opaque>
Réponse :
{ "data": {
"items": [...],
"next_cursor": "MTIz",
"has_more": true
} }
Si has_more vaut false, vous avez parcouru toute la ressource.
limit vaut 50 par défaut et est borné à 1–200 : une valeur hors plage ou non numérique est ajustée silencieusement, pas rejetée. Les pages sont parcourues du plus récent au plus ancien : le curseur pointe donc sur le dernier élément reçu.
⚠️ Attention — Un curseur malformé est ignoré en silence
Un cursor tronqué ou corrompu ne renvoie pas bad_request — il est ignoré et la liste repart du plus récent enregistrement. Traitez le jeton comme totalement opaque, renvoyez-le octet pour octet, et arrêtez-vous quand has_more vaut false ; sinon, un client qui abîme le jeton rechargera indéfiniment la page 1.
Endpoints non paginés par curseur
GET /v1/keysetGET /v1/webhooksrenvoient le tableauitemscomplet, sansnext_cursornihas_more.GET /v1/usage/historyfonctionne par plage viafrom/to(90 jours maximum) et renvoierows.