Toutes les listes utilisent une pagination par curseur (pas de ?page=N). Plus stable que l’offset : pas de saut si la collection mute pendant la pagination.

Format

Requête :
Réponse :
  • nextCursor: null → fin de la collection
  • limit : défaut 20, plafonné silencieusement à 100 (jusqu’à 500 pour les payouts, settlements et transactions wallet) ; une valeur supérieure n’est pas rejetée mais ramenée au plafond

Avec le SDK

Lecture page par page

Async iterator (recommandé)

L’iterator gère le curseur tout seul, s’arrête à nextCursor: null. Disponible sur toutes les ressources : paymentIntents, payouts, invoices, products.

Filtres

Liste-spécifiques (voir la référence API par endpoint) :
  • Payment Intents : status, assetCode, source, from, to
  • Payouts : status, assetCode, payoutType
  • Invoices : status, from, to
  • Products : isActive

Ordre

Par défaut : createdAt DESC (plus récent d’abord).

Limites de profondeur

Pas de limite hard sur la profondeur de pagination : vous pouvez itérer sur des millions de payment intents. Mais préférez les filtres de date :
Le cursor est opaque : ne le parsez pas. Sa structure peut changer sans préavis. Conservez-le tel quel et renvoyez-le.