Qu'est-ce qu'une API d'expédition et comment fonctionne-t-elle en 2027 ?
Une API d’expédition est une interface logicielle qui permet à une application d’échanger des informations d’expédition avec un transporteur, une plateforme logistique, une marketplace ou un service d’expédition. Au lieu d’obliger un utilisateur à saisir manuellement les détails de l’envoi dans un tableau de bord distinct, un système intégré peut envoyer des données, recevoir une réponse, créer ou récupérer des informations d’expédition et mettre automatiquement à jour le flux de traitement de la commande. En 2027, le terme désignera toujours une connexion entre des systèmes, mais les fonctions exactes dépendront du fournisseur : certaines API d’expédition se concentrent sur les tarifs et les étiquettes, tandis que d’autres se concentrent sur le suivi, les événements de livraison, les données d’adresse ou les retours.
Pour une entreprise de commerce électronique, la valeur pratique ne réside pas dans l’API elle-même. Elle réside dans un processus d’expédition mieux connecté : moins de saisies répétées, des transmissions opérationnelles plus rapides, un statut d’expédition plus clair et un meilleur contrôle sur ce que les clients voient après l’expédition d’une commande.
Que fait une API d’expédition ?
Une API d’expédition connecte une application à des services liés à l’expédition au moyen de requêtes et de réponses structurées. L’application peut être une boutique en ligne, un système de gestion des commandes, une plateforme d’entreposage, un système de planification des ressources d’entreprise, un outil de service client ou une application interne personnalisée.
Une requête type contient des informations telles qu’une référence de commande, le lieu d’expédition, la destination, les dimensions du colis, le poids du colis, la préférence de service et les informations sur le transporteur. Le service destinataire valide la requête et renvoie les données dans un format lisible par machine, généralement JSON. La réponse peut contenir les services d’expédition disponibles, un numéro de suivi, une référence d’étiquette, un identifiant d’expédition ou une erreur expliquant pourquoi la requête n’a pas pu être traitée.
L’expression « API d’expédition » est générale. Avant de choisir un fournisseur, identifiez les fonctions dont vous avez réellement besoin :
- Comparaison des tarifs : demande des services disponibles et des prix d’expédition en fonction de l’origine, de la destination, des détails du colis et d’autres règles.
- Création d’expédition : envoi des informations d’expédition à un transporteur ou à une plateforme d’expédition et réception d’un enregistrement d’expédition.
- Génération d’étiquettes : création d’une étiquette d’expédition imprimable ou utilisable électroniquement lorsque le fournisseur prend cette fonction en charge.
- Suivi : demande du dernier statut de l’expédition ou abonnement aux mises à jour de statut.
- Événements de livraison : réception d’étapes telles que l’acceptation, le transit, l’exception, la mise en livraison ou la livraison lorsque ces événements sont fournis par le transporteur ou le fournisseur de suivi.
- Services d’adresse : validation, normalisation ou vérification des adresses lorsque le fournisseur sélectionné offre cette fonctionnalité.
- Retours : création d’expéditions de retour, d’étiquettes de retour ou de mises à jour du statut des retours lorsque les retours sont inclus dans l’intégration.
Ces fonctionnalités sont souvent vendues séparément. Une API de suivi peut être utile même lorsque les étiquettes et les tarifs sont gérés ailleurs. À l’inverse, une API d’étiquettes peut créer une expédition sans fournir l’expérience post-achat dont une équipe de commerce électronique a besoin.
Comment fonctionne une API d’expédition
1. L’entreprise définit le flux de travail
Avant de créer toute connexion technique, l’entreprise décide quel événement doit déclencher une requête API. Par exemple, une boutique peut demander un tarif d’expédition lorsqu’un acheteur saisit une adresse de livraison. Un système d’exécution des commandes peut créer une étiquette après la mise en préparation d’une commande. Une page de suivi destinée aux clients peut demander les événements d’expédition après l’enregistrement d’un numéro de suivi.
Cette décision est importante, car une même commande peut passer par plusieurs systèmes. Une intégration doit attribuer clairement la responsabilité de chaque action et définir une source fiable pour chaque champ. Le système de commande peut être responsable du numéro de commande, le système d’entreposage des dimensions du colis, et le transporteur ou le fournisseur de suivi des événements d’expédition.
2. L’application s’authentifie
La plupart des API d’expédition exigent une authentification. Le fournisseur peut délivrer une clé API, un jeton d’accès ou un autre identifiant. L’application envoie cet identifiant avec sa requête afin que le service puisse reconnaître le compte et appliquer les autorisations appropriées.
Les identifiants doivent être stockés sur un serveur sécurisé plutôt que d’être exposés dans le code du navigateur ou les fichiers d’une application mobile. L’accès doit être limité aux fonctions et aux environnements qui en ont besoin. Des identifiants distincts pour les tests et la production peuvent faciliter le contrôle des modifications et l’analyse des erreurs.
3. L’application envoie une requête structurée
La requête utilise généralement une méthode HTTP telle que GET ou POST et comprend une URL, des informations d’authentification, des en-têtes et un corps. Le corps contient les données d’expédition requises par le point de terminaison. Une requête de suivi peut inclure un numéro de suivi et un identifiant de transporteur. Une requête d’étiquette peut nécessiter les informations relatives à l’expéditeur, au destinataire, au colis, au service et aux formalités douanières.
La qualité des données constitue une part majeure de l’intégration. Un code postal manquant, un code pays invalide, un service non pris en charge, une unité de poids incorrecte ou un identifiant de transporteur incohérent peut générer une erreur ou un résultat inutilisable. L’implémentation doit valider les données avant leur envoi et enregistrer la référence de requête nécessaire au support sans consigner inutilement d’informations sensibles.
4. Le service valide et traite la requête
Le fournisseur vérifie si la requête est correctement formatée et si le compte est autorisé à effectuer l’opération demandée. Il peut ensuite interroger un transporteur, mapper la réponse dans son propre modèle de données, appliquer les paramètres du compte ou traiter la requête de manière asynchrone.
Toutes les réponses ne sont pas immédiates. Un fournisseur peut renvoyer un résultat terminé, une requête acceptée ou une erreur. Si le traitement se poursuit après la requête initiale, l’application peut devoir interroger le service pour obtenir un résultat ou recevoir ultérieurement une notification webhook. La documentation doit déterminer le modèle pris en charge ; une intégration ne doit pas supposer que chaque point de terminaison fonctionne de manière synchrone.
5. L’application traite la réponse
Une réponse réussie peut inclure une liste de tarifs, des données d’étiquette, un identifiant d’expédition, un numéro de suivi ou des événements de suivi. L’application stocke les champs dont elle a besoin et les transmet à l’étape suivante du flux de travail. Par exemple, un système d’entreposage peut enregistrer le numéro de suivi avec la commande, tandis qu’un service de notification client utilise le même numéro pour créer un lien de suivi.
La gestion des erreurs est tout aussi importante. Une intégration en production doit distinguer une entrée invalide, un échec d’authentification, un problème temporaire du fournisseur, un rejet du transporteur, une réponse de limitation de débit et une expédition ne présentant aucun nouvel événement de suivi. Réessayer toutes les erreurs de la même manière peut créer des expéditions en double ou générer un trafic inutile.
6. Les mises à jour d’expédition sont synchronisées
Les informations de suivi ne constituent pas toujours une réponse finale unique. Le statut d’une expédition peut évoluer au fil du temps, et différents transporteurs peuvent utiliser des noms d’événements, des horodatages, des lieux et des descriptions d’exception différents. Une intégration de suivi peut demander périodiquement des mises à jour ou recevoir des webhooks lorsque de nouvelles informations sont disponibles.
L’entreprise doit définir la manière dont elle gère les événements en double, les événements retardés, les événements dans le désordre, les horodatages contradictoires et une expédition qui ne reçoit plus de mises à jour. Elle doit également décider quel statut est affiché aux clients et quels événements internes déclenchent une action du service client ou des opérations.
API d’expédition contre API de suivi
Une API de suivi est un type d’API d’expédition, mais les deux termes ne sont pas interchangeables. Une API d’expédition plus générale peut prendre en charge les tarifs, la création d’expéditions, les étiquettes et le suivi. Une API de suivi est principalement conçue pour récupérer ou diffuser des informations sur le statut des expéditions.
| Type d’API | Entrée habituelle | Sortie habituelle | Responsable courant |
|---|---|---|---|
| API de tarifs | Origine, destination, détails du colis | Services et tarifs disponibles | Paiement ou opérations d’expédition |
| API d’étiquettes | Données d’expédition, d’adresse, de colis et de service | Données d’étiquette, référence d’expédition et souvent numéro de suivi | Exécution des commandes ou opérations d’entreposage |
| API de suivi | Numéro de suivi et, si nécessaire, transporteur | Statut de l’expédition et historique des événements | Expérience client, assistance ou opérations |
| API de retours | Données de commande, de retour, d’adresse et de colis | Autorisation de retour, étiquette ou statut | Service client ou logistique inverse |
Les limites varient selon le fournisseur. Consultez toujours la documentation du point de terminaison plutôt que de choisir un produit uniquement en fonction de son nom.
Comment les équipes de commerce électronique utilisent une API d’expédition
Une entreprise de commerce électronique peut utiliser une API d’expédition à plusieurs étapes du cycle de vie d’une commande :
- Paiement : la boutique demande des options ou des tarifs de livraison en utilisant la destination et les informations sur le colis disponibles lors du paiement.
- Attribution de la commande : le système de commande envoie les données d’exécution à un entrepôt, un transporteur ou une plateforme d’expédition.
- Expédition : le flux d’exécution crée ou enregistre l’expédition et associe le numéro de suivi à la commande.
- Communication post-achat : l’entreprise utilise les événements d’expédition pour mettre à jour une page de commande, envoyer des notifications ou transmettre les exceptions au personnel d’assistance.
- Analyse de la livraison : les équipes opérationnelles utilisent les données d’événements pour identifier les retards récurrents, les problèmes de transporteur ou les écarts entre l’exécution et la livraison.
- Retours : un flux distinct ou connecté crée une expédition de retour et suit son acheminement vers le marchand ou un centre de traitement.
Pour les opérations faisant appel à plusieurs transporteurs, une API de suivi peut réduire la nécessité de gérer une connexion distincte destinée aux clients pour chaque transporteur. 17TRACK fournit une Tracking API pour les intégrations destinées aux développeurs, et sa documentation décrit le processus d’intégration et les points de terminaison disponibles. Les entreprises doivent vérifier les transporteurs pris en charge, les champs d’événement, la méthode d’authentification, les limites d’utilisation et les conditions commerciales avant de la sélectionner pour la production.
Une API de suivi peut également se situer entre un réseau de transporteurs et un système de gestion des commandes. Cette architecture peut simplifier la couche applicative, mais elle ajoute une dépendance supplémentaire. L’entreprise reste responsable du mappage correct des statuts, du contrôle de la qualité des données et de l’explication aux clients du fait que les mises à jour des transporteurs peuvent être retardées ou incomplètes.
Points à vérifier avant de choisir une API d’expédition
Adéquation fonctionnelle
Notez les opérations exactes requises : tarifs, étiquettes, suivi, webhooks, validation d’adresses, données douanières, retours ou rapports. Un fournisseur performant pour le suivi peut ne pas convenir à l’achat d’étiquettes, et une API propre à un transporteur peut ne pas couvrir un flux faisant appel à plusieurs transporteurs.
Adéquation des transporteurs et de la couverture géographique
Vérifiez si l’API prend en charge les transporteurs, pays, types de services et directions d’expédition utilisés par l’entreprise. La couverture doit être vérifiée pour les itinéraires et types de colis réels, et non déduite d’une affirmation générale concernant la prise en charge mondiale. Pour les expéditions transfrontalières, vérifiez comment l’intégration gère les informations douanières, les partenaires de livraison locaux et les événements après une remise.
Modèle de données et qualité des événements
Comparez les champs renvoyés par l’API avec ceux requis par la boutique, l’équipe d’assistance, le système d’analyse et l’entrepôt. Faites attention aux horodatages des événements, aux données de localisation, aux codes d’exception, à la preuve de livraison, aux informations de livraison estimée et à l’historique des statuts. Si un champ requis n’est pas documenté, considérez qu’il doit être confirmé pendant les tests.
Fiabilité et contrôles opérationnels
Examinez l’authentification, les limites de débit, les délais d’attente, les recommandations de nouvelle tentative, la sécurité des webhooks, l’idempotence, la gestion des versions, l’accès à l’environnement de test et la communication en cas d’incident. Demandez comment l’intégration doit se comporter lorsqu’un transporteur est temporairement indisponible ou lorsqu’un même événement est livré plusieurs fois.
Exigences commerciales et de conformité
La tarification peut dépendre du fournisseur, du point de terminaison, du volume d’expéditions, du compte transporteur ou du contrat. N’estimez pas le coût total à partir des seuls appels API. Incluez le développement, la surveillance, l’assistance, les frais des transporteurs, le stockage des données et le coût de gestion des requêtes échouées ou dupliquées. L’examen juridique et de la confidentialité doit couvrir les adresses des clients, leurs coordonnées, les données d’expédition, la conservation et les transferts de données pertinents pour l’entreprise.
Liste de contrôle d’implémentation pour 2027
Les principes techniques d’une API d’expédition ne changeront probablement pas simplement parce que le calendrier passe à 2027. Cependant, les points de terminaison, la prise en charge des transporteurs, la tarification, les exigences d’authentification et les champs de données peuvent évoluer. Utilisez la documentation actuelle du fournisseur et son environnement de test au début du projet.
- Définissez l’événement métier qui déclenche chaque requête API.
- Attribuez la responsabilité des données de commande, de colis, de suivi et de statut client.
- Mappez les unités, les codes pays, les codes transporteurs, les noms de services et les fuseaux horaires avant le développement.
- Utilisez des cas de test pour les expéditions nationales, transfrontalières, multi-colis, avec erreur d’adresse, annulées, retournées et retardées.
- Rendez les opérations de création idempotentes lorsque le fournisseur prend en charge un mécanisme d’idempotence.
- Stockez les références du fournisseur et les identifiants de requête à des fins de rapprochement et d’assistance.
- Traitez correctement les événements de suivi en double et dans le désordre.
- Configurez des alertes pour les erreurs d’authentification, les taux d’échec élevés, les webhooks retardés et les volumes inhabituels de création d’expéditions.
- Documentez une procédure de secours en cas d’interruption du fournisseur ou du transporteur.
- Examinez à nouveau la documentation du fournisseur avant le lancement et après toute modification importante de l’API.
La meilleure API d’expédition n’est donc pas nécessairement celle qui possède la liste de fonctionnalités la plus longue. C’est celle dont les fonctionnalités documentées, la couverture des transporteurs, la qualité des données, les contrôles de fiabilité et le modèle commercial correspondent au flux de travail que l’entreprise doit gérer. Un petit détaillant peut n’avoir besoin que du suivi et des notifications clients, tandis qu’une grande opération d’exécution des commandes peut avoir besoin de la sélection des tarifs, de la création d’étiquettes, de la gestion de plusieurs colis, des retours et d’un rapprochement détaillé. Considérez ces besoins comme des problèmes d’intégration différents plutôt que de supposer qu’une seule API peut tous les résoudre.
FAQ
Une API d’expédition est-elle la même chose qu’une API de transporteur ?
Non. Une API de transporteur est fournie par un transporteur spécifique ou connectée à celui-ci et expose généralement les services de ce transporteur. Une API d’expédition peut se connecter à un transporteur, à plusieurs transporteurs ou à une plateforme logistique qui normalise les informations provenant de plusieurs sources. La couverture et les fonctions réelles dépendent du fournisseur.
Une API d’expédition peut-elle créer des étiquettes ?
Certaines le peuvent, mais pas toutes. La création d’étiquettes nécessite généralement les informations d’expédition, d’adresse, de colis et de service, et peut nécessiter un compte transporteur ou un accord de facturation. Confirmez que la génération d’étiquettes est incluse dans le produit sélectionné et que les transporteurs et services pris en charge correspondent au flux de travail de l’entreprise.
Une API de suivi modifie-t-elle l’emplacement physique d’une expédition ?
Non. Une API de suivi signale ou diffuse les informations d’expédition fournies par un transporteur ou une source de données logistiques. Elle ne contrôle pas le déplacement physique d’un colis. Si le transporteur n’a pas scanné un article ou a retardé une mise à jour, l’API peut ne disposer d’aucun nouvel événement à renvoyer.
Une petite entreprise de commerce électronique devrait-elle créer une intégration d’API d’expédition ?
Cela dépend du flux de travail requis et des ressources techniques disponibles. Si l’entreprise a besoin d’une seule connexion simple à un transporteur, une application de commerce électronique ou d’expédition existante peut être plus pratique. Une intégration personnalisée devient plus intéressante lorsque l’entreprise a besoin d’une combinaison particulière de transporteurs, de systèmes de commande, d’expériences de suivi ou d’automatisations que les outils existants ne proposent pas.
Quelle est la première étape pour sélectionner une API d’expédition ?
Établissez la liste des décisions et des mises à jour exactes que le système doit automatiser. Comparez ensuite les fournisseurs en fonction de ces exigences, notamment la couverture des transporteurs, les points de terminaison pris en charge, les champs d’événement, l’authentification, les limites, les outils de test, l’assistance, la tarification et les procédures de secours. Une petite preuve de concept utilisant des scénarios de flux de travail réels peut révéler des lacunes qu’une liste de fonctionnalités ne montre pas.
