Récupérez les PV d’inspection, le PV signé, les bons et factures d’une mission, listez les documents à signer, et joignez vos propres pièces jointes.
Chaque mission de transport produit des documents : procès-verbaux (PV) d’inspection au départ et à l’arrivée, PV signé, bons de livraison, factures. Ce guide explique comment les lister, suivre leur statut de validation, repérer ceux qui doivent encore être signés, et joindre vos propres pièces.
Seuls les documents à visibilité client sont exposés par l’API. Les documents
internes (pièces convoyeur, justificatifs RH, etc.) ne sont jamais renvoyés, quel
que soit votre scope.
Tous les endpoints de ce guide sont scopés au groupe de votre clé API. Une mission qui n’appartient pas à votre groupe renvoie 404 (jamais 403). Les requêtes GET exigent le scope transports:read ; l’ajout de documents (POST) exige transports:write.
Renvoie la liste des documents visibles client de la mission. Chaque entrée décrit un document (PV, bon, facture…) avec son lien de téléchargement et son statut de validation.
Clé technique stable du document (document_key). Utilisez-la pour identifier un
type de document (PV de départ, PV signé, bon, facture…) plutôt que le label,
qui est un libellé d’affichage.
Document en attente de validation (déposé, pas encore vérifié).
accepted
Document validé.
refused
Document refusé — le motif de refus n’est pas exposé par l’API.
null
Statut non applicable (document informatif, sans cycle de validation).
Branchez votre logique métier sur key et status, pas sur label. Le label
est un texte d’affichage susceptible d’évoluer, tandis que key et status sont
des valeurs stables.
Renvoie uniquement les documents qui nécessitent une signature (typiquement les PV à faire contresigner). Utile pour piloter un rappel ou un flux de signature côté client.
La structure de chaque entrée est identique à celle de GET /transports/{id}/documents (voir Champs d’un document). Cet endpoint applique simplement un filtre supplémentaire sur les documents qui attendent une signature.
Le PV signé est exposé comme tout autre document, via GET /transports/{id}/documents. Pour le récupérer :
1
Listez les documents de la mission
Appelez GET /transports/{id}/documents et repérez l’entrée dont la key
correspond au PV signé.
2
Vérifiez le statut
Attendez que status vaille accepted pour être sûr que le PV signé est
finalisé et validé.
3
Téléchargez le fichier
Suivez l’url de l’entrée pour récupérer le PDF.
Node.js
const res = await fetch( "https://api.myexpressdriver.com/v1/transports/-O9xAbCdEf/documents", { headers: { "X-Api-Key": process.env.MED_API_KEY } });const { data } = await res.json();// On cible le PV signé qui a été validé.const pvSigne = data.find( (doc) => doc.key === "PV_ARRIVEE_SIGNE" && doc.status === "accepted");if (pvSigne?.url) { console.log("PV signé disponible :", pvSigne.url);} else { console.log("PV signé pas encore validé.");}
Plutôt que d’interroger l’endpoint en boucle (polling), abonnez-vous aux webhooks
document.added et document.accepted. Vous serez notifié dès que le PV signé
est déposé puis validé. Voir Vue d’ensemble des webhooks.
Attache un ou plusieurs documents à la mission. Chaque document est décrit par un name (libellé) et un link (URL HTTPS publiquement accessible depuis laquelle MED récupère le fichier).
L’endpoint renvoie 207 Multi-Status : chaque document est traité indépendamment, et la réponse détaille le résultat document par document. Un document peut échouer (lien injoignable, format invalide…) sans faire échouer les autres.
Réponse 207
{ "data": [ { "name": "Bon de commande client", "success": true, "error": null }, { "name": "Mandat de transport", "success": false, "error": "Le lien n'a pas pu être téléchargé." } ]}
Comme la réponse est un 207, le code HTTP ne reflète pas le succès de chaque
document : inspectez toujours le champ success de chaque entrée du tableau
data, et rejouez sélectivement les documents en échec.
