L’API Transport My Express Driver s’authentifie avec une clé API envoyée dans l’en-tête X-Api-Key. Il n’existe aucun mode anonyme : toute requête sans clé valide est rejetée. Chaque clé est rattachée à un groupe (flotte, concession ou loueur). Le groupe détermine deux choses :
  • le contexte d’autorisation — vous ne voyez et ne modifiez que les missions de votre groupe ;
  • la grille tarifaire appliquée lors de l’estimation et de la création de missions.
curl https://api.myexpressdriver.com/v1/transports \
  -H "X-Api-Key: med_live_a1b2c3d4e5f6g7h8i9j0"
Base URL de production : https://api.myexpressdriver.com/v1. Toutes les requêtes passent par HTTPS.

L’en-tête X-Api-Key

Ajoutez votre clé dans l’en-tête X-Api-Key de chaque requête.
X-Api-Key
string
requis
Clé API au format med_live_… (production) ou med_test_… (test). Toujours envoyée côté serveur, jamais exposée au navigateur.
curl https://api.myexpressdriver.com/v1/transports \
  -H "X-Api-Key: med_live_a1b2c3d4e5f6g7h8i9j0"
Stockez la clé dans une variable d’environnement (MED_API_KEY) ou un coffre de secrets, jamais en clair dans votre code source ni dans un dépôt Git.

Une clé = un groupe

Une clé API n’est jamais « globale ». Elle est émise pour un groupe précis et hérite de son périmètre.

Périmètre d'autorisation

Vous n’accédez qu’aux missions de votre groupe. Une mission appartenant à un autre groupe est traitée comme inexistante.

Grille tarifaire

L’estimation (POST /pricing) et la création (POST /transports) utilisent la grille négociée pour votre groupe.
Isolation par groupe. Une mission qui n’appartient pas au groupe de votre clé renvoie 404 Not Found (et non 403 Forbidden), afin de ne pas révéler son existence. Vérifiez toujours que vous interrogez un identifiant de votre groupe.

Scopes

Chaque clé porte un ou plusieurs scopes qui déterminent les opérations autorisées. Une clé peut être limitée à la lecture seule, ou autorisée à créer et modifier des missions.
ScopeAutoriseMéthodes couvertes
transports:readLecture des missions, positions, documents, événementsGET
transports:writeCréation, modification et annulation de missionsPOST, PATCH, DELETE
Si une requête exige un scope absent de la clé, l’API renvoie 403 Forbidden :
{
  "type": "about:blank",
  "title": "Forbidden",
  "status": 403,
  "detail": "Missing required scope: transports:write"
}
Pour un tableau de bord en lecture seule, émettez une clé limitée à transports:read. Réservez transports:write aux intégrations qui créent réellement des missions.

Environnements : live et test

L’API distingue deux environnements par le préfixe de la clé.

Production

Préfixe med_live_. Les missions sont réelles, attribuées à de vrais convoyeurs et facturées.

Test

Préfixe med_test_. Pour développer et valider votre intégration sans impact opérationnel.
Le préfixe est visible sur les premiers caractères de la clé, ce qui permet de repérer d’un coup d’œil dans quel environnement vous opérez.
Ne mélangez jamais les environnements. Une clé med_test_ ne donne pas accès aux données de production, et inversement. Cantonnez chaque clé à sa configuration (variables d’environnement séparées) pour éviter d’envoyer du trafic de test en production.

Gérer ses clés dans la console

Les clés se créent et se révoquent depuis la console client, dans l’onglet « API & Intégrations » du profil. Cet onglet n’est accessible qu’aux administrateurs de groupe.
1

Ouvrir l'onglet API & Intégrations

Connectez-vous à la console, ouvrez votre profil et sélectionnez l’onglet API & Intégrations. Si vous administrez plusieurs groupes, choisissez le groupe pour lequel émettre la clé.
2

Créer une clé

Cliquez sur Créer une clé, donnez-lui un libellé descriptif (ex. « Backend facturation »), choisissez l’environnement (live ou test) et les scopes (transports:read, transports:write).
3

Copier la clé immédiatement

La clé en clair s’affiche une seule fois. Copiez-la et placez-la dans votre coffre de secrets. Elle ne sera plus jamais ré-affichée.
4

Révoquer si nécessaire

Pour désactiver une clé compromise ou inutilisée, utilisez Révoquer. La révocation est immédiate et définitive : toute requête portant cette clé renverra alors 401.
La clé n’est montrée qu’une seule fois, à sa création. La console n’affiche ensuite que son préfixe (med_live_a1b2…), son libellé et sa date de dernière utilisation. Si vous perdez la clé en clair, vous ne pouvez pas la récupérer : révoquez-la et créez-en une nouvelle.

Sécurité des clés

Une clé API donne accès aux missions et aux données de votre groupe. Traitez-la comme un mot de passe.
N’exposez jamais une clé côté client. Une clé med_live_… ne doit figurer ni dans du code front-end, ni dans une application mobile, ni dans une page web, ni dans une URL. Toute clé visible dans le navigateur doit être considérée comme compromise et révoquée immédiatement.

Stockage côté serveur

Conservez la clé dans un coffre de secrets (variables d’environnement chiffrées, gestionnaire de secrets). Les appels à l’API se font depuis votre backend.

Rotation régulière

Renouvelez vos clés périodiquement : créez la nouvelle clé, déployez-la, puis révoquez l’ancienne une fois la bascule terminée.

Une clé par usage

Émettez une clé distincte par intégration ou par environnement. En cas de fuite, vous révoquez une seule clé sans interrompre les autres.

Moindre privilège

N’accordez que les scopes strictement nécessaires. Une intégration de reporting n’a besoin que de transports:read.

Comportement fail-closed

L’authentification est fail-closed : en cas de doute, l’accès est refusé. Une clé manquante, inconnue, révoquée ou expirée renvoie systématiquement 401 Unauthorized. Il n’existe aucun repli silencieux vers un accès anonyme.
{
  "type": "about:blank",
  "title": "Unauthorized",
  "status": 401,
  "detail": "Invalid API key."
}
  • L’en-tête X-Api-Key est absent de la requête.
  • La clé est inconnue (jamais émise, ou mal copiée).
  • La clé a été révoquée depuis la console.
  • La clé a expiré (si une date d’expiration a été définie).
Vérifiez la valeur de X-Api-Key, l’environnement (med_live_ vs med_test_) et l’état de la clé dans la console.
La clé est authentifiée mais ne porte pas le scope requis par l’opération (par exemple un POST avec une clé limitée à transports:read). Émettez ou réémettez une clé avec le scope transports:write.
L’identifiant existe peut-être, mais hors du périmètre de votre clé. L’API renvoie 404 plutôt que 403 pour ne pas révéler l’existence de missions d’autres groupes. Vérifiez l’identifiant et le groupe.
Toutes les erreurs d’authentification suivent la RFC 9457 (Content-Type: application/problem+json). Branchez votre logique de gestion d’erreurs sur le champ status, pas sur le texte de detail qui peut évoluer.

Vérifier rapidement sa clé

Un appel en lecture sur /transports confirme que la clé est valide et correctement scopée.
curl -i https://api.myexpressdriver.com/v1/transports?limit=1 \
  -H "X-Api-Key: $MED_API_KEY"
# 200 → la clé est valide (transports:read)
# 401 → clé manquante, invalide, révoquée ou expirée
Une réponse 200 confirme que votre clé est valide et dispose du scope transports:read. Vous êtes prêt à intégrer l’API.

Étapes suivantes

Démarrage rapide

Créez votre première mission de bout en bout en quelques minutes.

Format des erreurs

Gérez les réponses RFC 9457 et les codes HTTP courants.

Webhooks

Recevez les événements de transport en temps réel, signés HMAC.