POST /transports planifie un transport de véhicule, le rend visible côté
convoyeurs, et déclenche l’événement webhook transport.created.
La mission créée porte le statut public
scheduled : elle est planifiée et
en attente d’attribution d’un convoyeur. Vous suivrez ensuite sa progression via
les statuts assigned, in_transit, awaiting_documents, under_review puis
completed.Prérequis
Clé API
Une clé portant le scope
transports:write, envoyée dans l’en-tête
X-Api-Key: med_live_....Adresses d'enlèvement et de livraison
Les champs
pickup et delivery sont requis, avec au minimum une adresse.Facturation
Le bloc
billing est requis (raison sociale, e-mail, adresse).Clé d'idempotence
Recommandée : un
Idempotency-Key unique pour éviter toute double création.Les champs du corps de la requête
Le corps est un objet JSON. Trois champs sont requis :pickup, delivery
et billing. Tous les autres sont optionnels.
Champs racine
Type de transport. Valeurs usuelles :
livraison, restitution,
conciergerie. En l’absence de valeur, le transport est traité comme une
livraison standard.Indique un transport sur plateau (camion porte-véhicule) plutôt qu’en
roulant. Impacte la tarification.
Indique que le carburant est remboursé au convoyeur sur cette mission.
Véhicule circulant sous plaques W garage (immatriculation provisoire
professionnelle).
Liste des clés d’options à appliquer à la mission (ex. lavage, plein de
carburant). Les clés disponibles dépendent de la grille de votre groupe.
Note libre attachée à la mission (consignes particulières, référence interne).
car — le véhicule
Caractéristiques du véhicule transporté.
Dans le contrat OpenAPI, l’objet véhicule est nommé
vehicle et accepte aussi
type, vin, brand et model. car est l’alias documenté côté guide ;
les deux pointent vers le même objet véhicule. Préférez vehicle si vous générez
votre client directement depuis l’OpenAPI.pickup — point d’enlèvement
Lieu, créneau et contact pour l’enlèvement du véhicule.
delivery — point de livraison
Lieu, créneau et contact pour la livraison du véhicule. Mêmes propriétés que
pickup.billing — facturation
Informations de facturation simplifiées de la mission.
return_trip — aller-retour
Décrit la jambe retour d’un transport aller-retour. Omettez ce champ (ou
passez
false) pour un aller simple.Le retour n’a pas d’adresse de départ à renseigner. Il part
automatiquement du lieu de livraison de l’aller (le convoyeur repart de là
où il vient de livrer). Vous ne précisez donc que la destination du retour
via
return_trip.delivery — jamais un point de départ.Exemple — aller simple
Exemple — aller-retour
Pour un aller-retour, ajoutez le blocreturn_trip avec le véhicule et le point
de livraison du retour.
Réponse 201 Created
En cas de succès, l’API renvoie 201 avec l’identifiant de la mission, sa
référence métier, son statut et le prix calculé.
Identifiant technique de la mission (
offer_id). À utiliser dans tous les
appels ultérieurs : GET /transports/{id}, suivi GPS, documents, etc.Référence métier lisible de la mission (ex.
M-54321).Statut public de la mission. À la création, vaut toujours
scheduled.Tarif calculé pour la mission. Le montant exposé est le HT facturé
(
amount_ht), dans la devise currency (EUR).Adresse d’enlèvement résolue (géocodée) effectivement enregistrée :
address normalisée, lat, lng, place_id. Contrôlez-la pour vérifier que
le point retenu est bien celui visé.Adresse de livraison résolue, même structure que
pickup.Pour un aller-retour : adresses résolues
pickup (= livraison de l’aller) et
delivery (destination du retour). null sur un aller simple.Conservez l’
id renvoyé : c’est lui qui identifie la mission pour le suivi, la
modification des dates, les options et l’annulation.Idempotence
La création de mission est l’opération la plus sensible aux doublons : un appel qui échoue côté réseau peut avoir réussi côté serveur. Pour vous protéger, envoyez systématiquement un en-têteIdempotency-Key (par exemple un UUID v4
que vous générez).
Première requête
Première requête
Exécutée normalement. La réponse est mise en cache et associée à la clé.
Même clé + même corps
Même clé + même corps
La réponse en cache est rejouée à l’identique, avec l’en-tête
Idempotent-Replayed: true. Une seule mission est créée.Même clé + corps différent
Même clé + corps différent
L’API renvoie
409 Conflict : la clé a déjà servi pour une requête
différente.Échec 5xx
Échec 5xx
Les réponses
5xx ne sont pas mises en cache : le verrou est libéré, vous
pouvez réessayer en toute sécurité avec la même clé.Erreurs
Les erreurs suivent la RFC 9457 (Content-Type: application/problem+json).
| Code | Cause | À faire |
|---|---|---|
401 | Clé API manquante, invalide ou révoquée | Vérifier l’en-tête X-Api-Key. |
403 | Scope transports:write absent | Demander une clé avec le bon scope. |
409 | Idempotency-Key réutilisée (corps ≠) | Utiliser une nouvelle clé ou renvoyer le même corps. |
422 | Validation : champ requis manquant | Lire le tableau errors[] du corps. |
429 | Limite de débit atteinte | Back-off et respecter l’en-tête Retry-After. |
502 | Échec d’un service amont (création/tarif) | Réessayer (l’idempotence rend la reprise sûre). |
422 lorsqu’un champ requis manque :
Étapes suivantes
Suivre une mission
Récupérer le détail, les positions GPS et l’ETA du convoyeur.
Modifier les dates
Ajuster les créneaux d’enlèvement et de livraison, par jambe.
Recevoir les événements
S’abonner aux webhooks signés (
transport.created, transport.status_changed…).