Chaque mission de transport suit un cycle de vie : de sa planification jusqu’à sa clôture (ou son annulation). L’API expose un vocabulaire de statuts public et stable — un sous-ensemble condensé des statuts internes — pour que vous puissiez piloter votre intégration sans dépendre des détails opérationnels. À chaque changement d’étape, un événement webhook est émis. C’est le signal canonique pour réagir en temps réel : mettre à jour votre back-office, notifier un client, déclencher une facturation.
Le statut public d’une mission est exposé via le champ status (objet Transport) sur GET /transports/{id} et GET /transports. Les statuts internes ne sont jamais renvoyés.

Les 9 statuts publics

scheduled

Mission planifiée, en attente d’attribution d’un convoyeur. C’est le statut initial après POST /transports.

assigned

Un convoyeur a été attribué à la mission. Le véhicule n’est pas encore enlevé.

in_transit

Le véhicule a été enlevé et est en cours d’acheminement vers le point de livraison (jambe aller).

in_transit_return

La jambe retour est en cours (uniquement pour les missions aller-retour).

awaiting_documents

Le véhicule est livré ; la mission attend les PV et documents (inspection, bon de livraison).

under_review

Les documents transmis sont en cours de validation.

completed

Mission terminée. Documents validés, prestation clôturée. Une mission annulée n’est jamais completed.

incident

Une anomalie a été signalée sur la mission (peut survenir à tout moment).

cancelled

Mission annulée, avant le départ du véhicule. Elle reste lisible (GET /transports/{id}, ?status=cancelled) et porte cancelled: true.
Branchez votre logique sur la valeur exacte du statut (completed, cancelled, …), jamais sur un libellé affiché. Ces neuf valeurs constituent un contrat stable.

Diagramme des transitions

Le chemin nominal va de scheduled à completed. La jambe in_transit_return n’apparaît que pour les aller-retours. L’état incident peut être atteint depuis n’importe quel état actif ; cancelled, seulement avant le départ du véhicule (scheduled, ou assigned une fois l’attribution du convoyeur confirmée). Résumé textuel de la séquence nominale :
incident et cancelled ne sont pas des étapes du flux nominal. Un incident peut intervenir à tout moment et ne clôt pas forcément la mission — il signale une anomalie à traiter. cancelled est une sortie définitive, possible tant que le véhicule n’est pas parti (voir Annuler la mission pour le barème des frais).

Cas de l’aller-retour (double jambe)

Une mission peut comporter une jambe retour lorsque le convoyeur doit ramener un véhicule après la livraison aller. Vous l’activez à la création via le champ return_trip (booléen ou objet).
Sur une mission aller-retour :
  • Le détail de la mission (GET /transports/{id}) porte un objet return_trip non null, qui contient son propre status, ses points pickup / delivery, son vehicle, sa distance_km et son price. Quand la mission est annulée, le retour l’est avec elle et son status vaut aussi cancelled.
  • Le résumé de listing (GET /transports) expose un booléen has_return pour repérer les aller-retours d’un coup d’œil.
  • Le statut public passe par in_transit_return pendant que la jambe retour est en cours. Si la mission est un trajet simple, ce statut n’apparaît jamais — on passe directement de in_transit à awaiting_documents.
Les endpoints de modification raisonnent par jambe. Pour les dates (PATCH /transports/{id}/dates), les clés possibles sont enlevement-aller, livraison-aller, enlevement-retour, livraison-retour. Pour la refacturation (POST /transports/{id}/price-adjustments), le champ leg vaut aller ou retour. Seules les jambes réellement modifiées déclenchent une notification.

Webhook émis à chaque transition

Chaque changement d’état projette un événement dans le journal de la mission, qui est ensuite livré à vos endpoints webhook. Le tableau ci-dessous associe une transition à l’événement correspondant.
L’événement générique transport.status_changed est émis à chaque transition de statut public et porte les deux statuts (from, to). Les événements plus spécifiques (transport.assigned, transport.collected, transport.completed, transport.incident, transport.cancelled) le doublent pour les étapes clés. Vous pouvez vous abonner uniquement à transport.status_changed pour suivre tout le cycle de vie avec un seul handler.
D’autres événements ne sont pas des transitions de cycle de vie mais accompagnent une mission active :
La livraison des webhooks est at-least-once : un même événement peut vous parvenir plusieurs fois. Déduplifiez sur l’en-tête X-MED-Delivery-Id, et prévoyez une réconciliation périodique via GET /events?since=… pour rattraper d’éventuels événements manqués. Voir Webhooks · Événements pour le catalogue complet et la vérification de signature.

Réagir à une transition (exemple)

Voici un handler de webhook minimal qui aiguille selon le statut public reçu. Le détail de la vérification de signature HMAC est traité dans la page webhooks.
Node.js

Étapes suivantes

Catalogue des événements webhook

Tous les types d’événements, leurs payloads, les en-têtes de livraison et la vérification de signature.

Démarrage rapide

Créez votre première mission et abonnez-vous à ses événements en quelques minutes.