Passer au contenu principal

Pagination

Découvrez comment l'API DZBuild utilise la pagination par curseur pour les endpoints de liste — récupération efficace de données via next_cursor et has_more.

Écrit par Support

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/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.

Avez-vous trouvé la réponse à votre question ?