Tous les points de terminaison qui renvoient une liste d'objets, comme GET /v1/transfers, paginent leurs résultats par curseur. Plutôt qu'un numéro de page, vous recevez à chaque réponse un jeton opaque (next_cursor) qui pointe vers la suite. Vous le renvoyez tel quel à l'appel suivant pour récupérer la page d'après. Ce modèle reste stable même quand de nouvelles ressources sont créées entre deux appels : aucune ligne n'est dupliquée ni sautée, contrairement à une pagination par décalage classique. Ce guide décrit les paramètres, les champs de réponse et la façon de parcourir un ensemble complet.
Paramètres de requête
Deux paramètres de chaîne de requête contrôlent la pagination. Ils s'ajoutent aux filtres propres à chaque point de terminaison (par exemple status ou search sur les transferts).
| Paramètre | Type | Description |
|---|---|---|
| limit | entier | Nombre maximum d'éléments par page. Plafonné à 100. Une valeur supérieure est ramenée à 100, une valeur inférieure à 1 est ramenée à 1. La valeur par défaut dépend du point de terminaison (20 pour les transferts). |
| cursor | chaîne | Jeton opaque renvoyé dans next_cursor par l'appel précédent. Omettez-le pour obtenir la première page. Traitez sa valeur comme opaque : ne la construisez ni ne la modifiez. |
Champs de réponse
Une réponse de liste a la forme suivante. Le tableau data contient les éléments de la page courante, dans l'ordre antéchronologique (les plus récents d'abord).
| Champ | Type | Description |
|---|---|---|
| object | chaîne | Toujours "list" pour une réponse paginée. |
| data | tableau | Les éléments de la page courante. Vide si l'ensemble ne contient aucun résultat. |
| has_more | booléen | true s'il existe encore des éléments au-delà de cette page, false si vous avez atteint la fin. |
| next_cursor | chaîne ou null | Jeton à passer en cursor pour la page suivante. Vaut null sur la dernière page (quand has_more est false). |
| limit | entier | La limite effectivement appliquée, après plafonnement. |
Récupérer la page suivante
Pour avancer d'une page, reprenez la valeur de next_cursor et placez-la dans le paramètre cursor de la requête suivante. Conservez les mêmes filtres et la même limit d'un appel à l'autre.
/v1/transfersListe les transferts du workspace, paginée par curseur (limit, cursor).Parcourir tout l'ensemble
Pour traiter la totalité des résultats, bouclez tant que next_cursor n'est pas null, en réinjectant le curseur à chaque tour. L'exemple ci-dessous parcourt tous les transferts et les accumule dans un tableau.
Pièges courants
- Ne vous fiez pas à
data.length < limitpour détecter la fin : utiliseznext_cursor === null(ouhas_more === false). Une page peut, dans de rares cas, contenir moins d'éléments quelimitsans être la dernière. - Ne réutilisez pas un curseur d'un point de terminaison ou d'un jeu de filtres sur un autre. Un curseur n'a de sens que pour la même liste, avec les mêmes filtres.
- Ne demandez pas plus de 100 éléments : toute valeur de
limitau-delà est silencieusement ramenée à 100. Lisez le champlimitde la réponse pour connaître la valeur réellement appliquée. - Gardez les filtres constants pendant la pagination. Changer
status,searchou un autre filtre en cours de parcours invalide la cohérence du curseur. - Ne stockez pas un curseur sur le long terme pour reprendre une liste plus tard : il reflète l'état au moment où il a été émis. Pour un instantané durable, parcourez l'ensemble en une fois.
- Conservez
limitidentique d'une page à l'autre. La changer en cours de route fonctionne, mais brouille le raisonnement sur le nombre d'appels restants.