Pagination

Les listes qui peuvent devenir volumineuses utilisent la pagination par curseur (produits, annonces, commandes, événements, opérations, actions, annonces ignorées, entreprises, commandes du Storefront) :

curl "https://api.nembol.com/rest/v1/products?limit=50" \
  -H "Authorization: Bearer $NEMBOL_API_KEY"

{
  "data": [ { "id": "…" } ],
  "has_more": true,
  "next_cursor": "eyJ1IjoiMjAyNi0wNy0yNFQx…"
}

Renvoyez next_cursor en tant que ?cursor= pour obtenir la page suivante. Quand has_more vaut false, vous avez terminé. limit va de 1 à 100 (25 par défaut). Les curseurs sont opaques. Ne les analysez pas et ne les conservez pas longtemps. Un curseur que Nembol n'a pas fourni (tronqué, modifié, vide) répond 422 validation_failed avec param: cursor : il n'est jamais interprété comme la première page.

Listes sans curseur

Quelques listes sont petites par nature, ou plafonnées, et sont renvoyées en une seule réponse. Elles n'ont ni limit ni cursor ; là où has_more est présent, il vaut toujours false.

Garantie d'ordre

Les listes sont triées de la plus récente à la plus ancienne, avec un départage stable par id : les produits et les annonces par updated_at, les commandes par created_at (le moment où la commande a été passée), les événements par created_at. Cet ordre fait partie du contrat. Les pages ne sautent ni ne répètent jamais d'éléments au sein d'un même parcours.

Synchronisation incrémentale

Pour garder un système externe synchronisé sans tout relire, parcourez la liste avec updated_after :

curl "https://api.nembol.com/rest/v1/products?updated_after=2026-07-24T00:00:00Z&limit=100" \
  -H "Authorization: Bearer $NEMBOL_API_KEY"

Notez l'horodatage du début du parcours, parcourez toutes les pages jusqu'à la fin, puis utilisez cet horodatage comme updated_after du parcours suivant. Les produits supprimés et fusionnés sortent de la liste par défaut : pour les retrouver lors d'un parcours, lisez aussi status=archived&updated_after=… (ou utilisez le webhook product.deleted). (Pour une synchronisation en mode push, utilisez plutôt les webhooks. Le parcours sert de solution de secours pour la réconciliation.)

Commandes modifiées. GET /orders?updated_after=… renvoie les commandes passées ou modifiées (statut, traitement, suivi : par ex. annulées ou remboursées sur le canal) après cette date ; le updated_at de chaque commande indique quand elle a été modifiée pour la dernière fois. Interrogez avec l'heure de votre interrogation précédente. En mode push, utilisez les webhooks order.created et order.status_changed.

Dernière mise à jour le 20 octobre 2026