# Pagination

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.

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[​](#endpoints-non-paginés-par-curseur "Lien direct vers Endpoints non paginés par curseur")

* `GET /v1/keys` et `GET /v1/webhooks` renvoient le tableau `items` complet, sans `next_cursor` ni `has_more`.
* `GET /v1/usage/history` fonctionne par plage via `from` / `to` (90 jours maximum) et renvoie `rows`.