next_cursor) d’une page à la suivante jusqu’à atteindre la fin. Ce modèle reste stable même quand des données sont créées pendant que vous itérez.
Toutes les requêtes ci-dessous utilisent la base URL
https://api.myexpressdriver.com/v1 et l’en-tête d’authentification X-Api-Key: med_live_....Principe
Une requête de liste accepte deux paramètres de requête :limit (taille de page) et cursor (position de départ). La réponse renvoie un tableau data et un next_cursor.
next_cursor dans le paramètre cursor :
next_cursor vaut null, vous avez atteint la dernière page : il n’y a plus rien à récupérer.
La condition d’arrêt d’une boucle de pagination est toujours
next_cursor === null. Ne vous fiez pas à data.length < limit : une page peut être pleine et pourtant être la dernière.Paramètres
Nombre maximal d’éléments par page. Le maximum dépend de l’endpoint (voir le tableau ci-dessous). Une valeur supérieure au maximum est plafonnée au maximum.
Jeton opaque renvoyé par le champ
next_cursor de la page précédente. À omettre pour récupérer la première page.Limites par endpoint
La taille de page par défaut et son maximum dépendent de l’endpoint.| Endpoint | limit par défaut | limit max |
|---|---|---|
GET /transports | 50 | 200 |
GET /events | 50 | 200 |
GET /webhooks/deliveries | 50 | 200 |
GET /transports/{id}/positions | 100 | 500 |
GET /transports/{id}/waypoints | 100 | 500 |
Les endpoints de tracking (
/positions, /waypoints) renvoient un objet { "data": [...] } borné par limit, sans champ next_cursor. Pour /positions, paginez plutôt par fenêtre temporelle avec le paramètre since (voir l’onglet « Positions » plus bas). La pagination par curseur (next_cursor) concerne /transports, /events et /webhooks/deliveries.Forme de la réponse
Le tableau d’éléments de la page courante. Vide (
[]) s’il n’y a aucun résultat.Le curseur à passer dans le paramètre
cursor pour obtenir la page suivante. Vaut null sur la dernière page.Boucle de pagination complète (Node.js)
Voici une fonction réutilisable qui suitnext_cursor jusqu’à null et accumule tous les éléments. Elle préserve les filtres d’origine (status, type, since, etc.) à chaque tour de boucle.
Variante curl (boucle shell)
Le même algorithme en Bash, avecjq pour lire next_cursor :
Cas particuliers selon l’endpoint
- Missions (/transports)
- Événements (/events)
- Livraisons webhook (/webhooks/deliveries)
- Positions (/positions)
Curseur classique. Combinez avec le filtre Statuts publics acceptés :
status (statut public) pour ne lister qu’un sous-ensemble :scheduled, assigned, in_transit, in_transit_return, awaiting_documents, under_review, completed, incident, cancelled.Bonnes pratiques
Traitez chaque page au fil de l'eau
Traitez chaque page au fil de l'eau
Sur de gros volumes, n’attendez pas d’avoir tout en mémoire : traitez (ou persistez) chaque page dès sa réception, puis passez au curseur suivant. Cela borne votre empreinte mémoire.
Gérez le débit (429) sans perdre votre place
Gérez le débit (429) sans perdre votre place
Si une page renvoie
429 Too Many Requests, attendez la durée indiquée par l’en-tête Retry-After (en secondes) puis rejouez la même requête avec le même curseur — ne l’avancez pas tant que la page n’a pas été récupérée avec succès.Ne mémorisez pas un curseur sur le long terme
Ne mémorisez pas un curseur sur le long terme
Le curseur sert à enchaîner les pages d’un même parcours. Pour reprendre une synchronisation ultérieurement, préférez le filtre
since (sur /events et /positions) plutôt que de stocker un curseur, dont le format est opaque et susceptible d’évoluer.Étapes suivantes
Démarrage rapide
Créez votre première mission et récupérez-la en quelques minutes.
Gestion des erreurs
Comprendre le format RFC 9457 et réagir aux codes 401, 422, 429.
Réconciliation des événements
Rejouez le journal
/events pour rattraper les webhooks manqués.