Les API des transporteurs d’expédition expliquées : UPS, FedEx, USPS, DHL et plus encore
Les API des transporteurs sont des connexions logicielles qui permettent à une boutique, un système de gestion d’entrepôt, une plateforme de gestion des commandes ou un outil de service client d’échanger des données d’expédition avec des transporteurs tels que UPS, FedEx, USPS et DHL. Elles peuvent prendre en charge des tâches comme les demandes de tarifs, la création d’étiquettes, la réservation d’expéditions, les mises à jour de suivi, la vérification des adresses et les notifications d’événements de livraison. La bonne approche d’API dépend moins du nom du transporteur que du processus que vous devez automatiser, des pays que vous desservez et des systèmes que vous utilisez déjà.
Une intégration avec un seul transporteur peut être efficace lorsque votre volume d’expédition et votre zone de service sont prévisibles. Une API multitransporteur est généralement plus pratique lorsqu’une activité compare les services, expédie à l’international ou a besoin d’un format de suivi unique pour plusieurs transporteurs. Ce guide présente les principaux types d’API, explique à haut niveau les différences entre les grands transporteurs et indique les éléments à vérifier avant de créer ou d’acheter une intégration.
Fonctionnement d’une API de transporteur
Une API, ou interface de programmation d’application, définit la manière dont deux systèmes logiciels échangent des requêtes et des réponses. Dans le domaine de l’expédition, votre application peut envoyer les détails du colis, les adresses d’origine et de destination, les préférences de service ainsi que les informations douanières. Le transporteur ou la plateforme d’expédition renvoie ensuite une réponse telle qu’un tarif d’expédition, les données d’une étiquette, un numéro de suivi ou un message d’erreur.
Les API de transporteurs remplissent normalement plusieurs fonctions distinctes :
- Tarification : demande un tarif d’expédition estimé ou basé sur un contrat pour un colis et un service.
- Création d’expédition : envoie les détails de l’expédition et reçoit un numéro de suivi ou une confirmation d’expédition.
- Génération d’étiquettes : produit une étiquette imprimable, souvent sous forme de PDF, d’image ou de données de document.
- Suivi : récupère les événements d’expédition, les statuts, les emplacements et les informations de livraison lorsqu’ils sont disponibles.
- Services d’adresse : valide, normalise ou complète les informations d’adresse, selon le transporteur et la destination.
- Enlèvement et manifeste : prend en charge les demandes d’enlèvement ou les documents d’expédition de fin de journée lorsque le compte et le service le permettent.
- Notifications : fournit des informations de statut par interrogation, webhooks, fonctionnalités d’e-mail ou autre mécanisme d’événement.
Ces fonctionnalités ne sont pas automatiquement incluses dans chaque compte d’API de transporteur. Un transporteur peut séparer les services en différents produits, exiger une approbation du compte ou limiter l’accès selon le pays, le type de service, l’accord client ou l’environnement technique. Considérez chaque fonctionnalité comme un élément à confirmer dans la documentation actuelle du transporteur, plutôt que comme une caractéristique déductible de l’existence d’une API.
API directes de transporteurs et API multitransporteurs
Il existe deux modèles d’intégration pratiques. Une intégration directe relie votre logiciel à la plateforme de développement d’un seul transporteur. Une intégration multitransporteur relie votre logiciel à un intermédiaire qui normalise plusieurs transporteurs derrière une interface unique.
| Modèle | Avantages | Compromis | Solution la plus adaptée |
|---|---|---|---|
| API directe de transporteur | Accès direct aux propres services, règles de compte et données d’expédition du transporteur | Identifiants, formats, tests, gestion des erreurs et maintenance distincts pour chaque transporteur | Une entreprise ayant un transporteur principal ou un processus spécialisé |
| API multitransporteur | Une seule intégration peut simplifier le suivi, la sélection du transporteur et la gestion normalisée des statuts | La couverture, la profondeur fonctionnelle, les exigences de compte et les conditions commerciales varient selon le fournisseur | E-commerce multitransporteur, marketplaces, 3PL et opérations transfrontalières |
Une API multitransporteur ne remplace pas nécessairement une relation directe avec un transporteur. Certaines fonctions d’expédition peuvent toujours nécessiter un compte transporteur, des tarifs négociés, une approbation ou une configuration directe. Il convient également de vérifier si l’intermédiaire crée des étiquettes, suit uniquement les expéditions existantes ou prend en charge les deux.
Comparaison des principales API de transporteurs
API UPS
UPS fournit des ressources pour les développeurs qui souhaitent connecter des applications professionnelles aux services UPS. Selon le compte, la région et le produit, les développeurs peuvent examiner des fonctionnalités telles que la tarification, l’expédition, le suivi, les services liés aux adresses et les processus d’enlèvement via l’environnement officiel de développement UPS.
UPS est souvent pris en considération par les entreprises qui gèrent un volume important de colis, qui ont besoin de services spécifiques à UPS ou qui disposent déjà d’un compte et d’un contrat UPS. La question pratique n’est pas simplement de savoir si UPS possède une API. Il faut déterminer si le service UPS concerné, le mode de facturation, la destination et le profil du colis peuvent être utilisés avec le produit d’API disponible pour votre compte.
Avant la mise en œuvre, confirmez le processus d’authentification actuel, la disponibilité du sandbox, les formats de requête pris en charge, le format de sortie des étiquettes, l’éligibilité aux tarifs, le comportement des événements de suivi et les exigences de migration. La documentation et les noms de produits UPS peuvent changer ; utilisez donc le portail officiel des développeurs UPS comme point de départ.
API FedEx
FedEx propose une plateforme de développement pour les applications qui doivent fonctionner avec les services d’expédition et de livraison FedEx. Sa documentation constitue la source appropriée pour vérifier les API disponibles, les identifiants, les environnements de test, les processus d’expédition, le suivi et les exigences propres à chaque service.
FedEx peut être particulièrement adapté lorsqu’une activité dépend des services FedEx ou nécessite un contrôle spécifique du transporteur sur les processus d’expédition et de suivi. L’effort d’intégration peut impliquer bien plus que l’envoi d’une adresse et la réception d’une étiquette. Les dimensions du colis, le choix du service, les informations du compte, les données douanières, les règles relatives aux marchandises dangereuses et les documents internationaux peuvent influencer la requête et la réponse.
Les équipes doivent tester les requêtes réussies comme les requêtes échouées. Par exemple, une application doit savoir gérer une adresse invalide, un service non pris en charge, une demande d’expédition en double, un champ douanier manquant et une interruption temporaire du transporteur. Consultez le portail des développeurs FedEx pour obtenir la documentation et les exigences d’accès actuelles.
API USPS
USPS fournit des ressources professionnelles et pour développeurs destinées aux applications utilisant les services USPS. USPS est particulièrement pertinent pour les processus nationaux américains liés aux colis et au courrier, tandis que les produits d’API exacts et les conditions d’accès doivent être vérifiés dans la documentation officielle actuelle.
Les intégrations USPS nécessitent des tests attentifs, car une entreprise peut devoir distinguer les produits postaux, les services de colis, les événements de suivi, les données d’adresse et les processus liés aux étiquettes ou aux frais de port. Une exigence limitée au suivi est fondamentalement différente d’une application qui doit acheter des frais de port ou générer des étiquettes d’expédition.
Ne supposez pas qu’une API USPS possède la même structure de requête, le même vocabulaire d’événements, la même disponibilité des services ou le même modèle de compte que UPS ou FedEx. Consultez les ressources pour développeurs USPS et confirmez quels produits sont disponibles pour votre cas d’utilisation, votre périmètre géographique et votre configuration de compte. Si votre entreprise a seulement besoin d’une vue de suivi cohérente entre plusieurs transporteurs, une API multitransporteur axée sur le suivi peut nécessiter moins de logique personnalisée que plusieurs intégrations directes.
API DHL
DHL est un groupe d’entreprises proposant différents services logistiques et de colis ; « l’API DHL » n’est donc pas un produit universel pour chaque expédition. Les ressources pour développeurs de DHL couvrent les API et les outils associés à ses services, mais le produit pertinent dépend de l’unité commerciale DHL, de la destination, du type d’expédition et de la relation de compte.
DHL est un choix naturel pour les expéditions internationales, les services express et les opérations transfrontalières, mais l’intégration appropriée doit toujours correspondre au service acheté. Vérifiez si la documentation concerne DHL Express, les services de colis e-commerce, le fret ou une autre offre DHL avant de concevoir le processus.
Vérifiez les pays pris en charge, les champs douaniers et de facture commerciale, les codes de service, le comportement du suivi, les formats d’étiquette et les exigences d’ouverture de compte dans le portail des développeurs DHL. Pour les mises en œuvre internationales, prévoyez un processus de gestion des exceptions douanières et des documents incomplets, plutôt que de considérer le suivi comme l’ensemble du cycle de vie de l’expédition.
Autres transporteurs
Les entreprises peuvent également avoir besoin de transporteurs régionaux ou nationaux tels que Canada Post, Royal Mail, Australia Post, DPD, GLS ou Japan Post. Leurs API diffèrent en matière de couverture, d’intégration initiale, de noms de services, de détail des événements de suivi, de formats d’étiquette et de prise en charge des expéditions internationales. « Plus de transporteurs » n’est donc pas automatiquement synonyme de meilleure solution. La couverture doit être mesurée en fonction des itinéraires, des services et des types d’expédition que vous utilisez réellement.
Pour un transporteur important pour votre activité, consultez d’abord sa propre documentation destinée aux développeurs. Si le transporteur est pris en charge par une plateforme tierce, confirmez si l’intégration est directe, si vous fournissez vos propres identifiants de transporteur et quelles fonctions sont disponibles. La prise en charge du suivi ne prouve pas que la tarification, la création d’étiquettes ou l’annulation d’expéditions sont également prises en charge.
API de suivi ou API d’expédition complète ?
De nombreux projets utilisent l’expression « API d’expédition » alors qu’ils ont en réalité besoin du suivi des expéditions. Il s’agit de périmètres différents. Une API de suivi accepte généralement un numéro de suivi et un transporteur, puis renvoie des événements normalisés ou un statut actuel. Une API d’expédition complète peut couvrir les tarifs, les étiquettes, la création d’expéditions, les documents douaniers et le suivi.
Si votre objectif principal est d’afficher l’avancement de la livraison sur un site e-commerce, un portail client ou un outil d’assistance, une intégration axée sur le suivi peut suffire. L’API de suivi de 17TRACK est un exemple de produit de suivi multitransporteur ; utilisez sa documentation pour vérifier la couverture actuelle des transporteurs, les formats de requête, l’authentification et le comportement des événements avant son adoption.
Si vous devez acheter des frais de port ou créer des étiquettes, le suivi seul ne suffira pas à finaliser le processus. Vous aurez peut-être besoin de comptes directs auprès des transporteurs, d’une plateforme d’expédition ou d’une API d’expédition multitransporteur disposant de fonctionnalités d’étiquetage documentées. La séparation précoce de ces exigences évite une erreur courante de mise en œuvre : sélectionner un produit de suivi et découvrir plus tard qu’il ne peut pas créer l’expédition dont votre entrepôt a besoin.
Éléments à vérifier avant de choisir une API
1. Définir le processus métier
Notez l’action exacte que le système doit effectuer. Il peut s’agir d’« afficher les événements de suivi après l’expédition d’une commande », de « sélectionner le service admissible le moins cher », de « créer une étiquette dans l’entrepôt » ou de « prévenir un client lorsque la livraison est retardée ». Chaque action implique des données, une gestion des erreurs et des exigences opérationnelles différentes.
2. Associer les transporteurs aux itinéraires et aux services
Répertoriez les pays d’origine, les pays de destination, les types de colis, les niveaux de service, les processus de retour et les marchandises réglementées éventuelles. Un transporteur peut être techniquement pris en charge tout en étant inadapté à un itinéraire ou à un service donné. Pour les expéditions internationales, incluez les données douanières, les droits, les taxes et les documents commerciaux dans les exigences.
3. Confirmer les prérequis d’accès et les conditions commerciales
Vérifiez si l’API exige un compte transporteur, une configuration de facturation, une approbation, des tarifs négociés, un jeton d’application ou une validation de production. Les identifiants de test et de production peuvent être différents. Ne placez jamais de secrets de production dans du code exécuté dans le navigateur ou dans des dépôts publics ; utilisez une intégration sécurisée côté serveur et renouvelez les identifiants conformément à votre politique de sécurité.
4. Comparer la qualité des données, pas seulement le nombre de points de terminaison
Demandez comment l’API représente le statut de l’expédition, la livraison estimée, les exceptions de livraison, la preuve de livraison, les scans, les retours et les expéditions de plusieurs colis. Une longue liste de points de terminaison ne garantit pas un niveau de détail utile pour les événements. Décidez comment votre application normalisera les statuts tels que étiquette créée, en transit, en cours de livraison, livré, exception et retourné.
5. Tester les scénarios d’échec et de changement
Une intégration prête pour la production doit gérer les délais d’attente, les limites de débit, les requêtes en double, les adresses invalides, les scans manquants, les interruptions du transporteur, les changements de numéros de suivi et les événements tardifs ou reçus dans le désordre. Utilisez l’idempotence lorsque l’API la prend en charge, enregistrez les identifiants de requête et rendez les nouvelles tentatives sûres. Les systèmes de suivi doivent également tolérer les périodes sans nouveau scan au lieu de considérer chaque période silencieuse comme une erreur.
6. Évaluer le coût de maintenance
Les API des transporteurs évoluent. Les mises à jour de versions, les changements de certificats, les modifications de codes de service, les nouveaux champs douaniers et les points de terminaison retirés peuvent affecter les opérations. Demandez qui surveille les changements de documentation, qui est responsable de la réponse aux incidents et à quelle vitesse l’intégration peut être mise à jour. Un fournisseur multitransporteur peut réduire le nombre d’intégrations gérées par votre équipe, mais il introduit une dépendance qui doit être évaluée en matière de continuité de service et de qualité de l’assistance.
Cadre de décision pratique
Choisissez une API directe de transporteur lorsqu’un transporteur domine vos expéditions, que vous avez besoin de fonctions spécifiques à ce transporteur et que votre équipe peut maintenir l’intégration. Choisissez une API d’expédition multitransporteur lorsque vous avez besoin de tarifs, d’étiquettes et de création d’expéditions auprès de plusieurs transporteurs dans un seul processus, à condition que les services requis soient réellement pris en charge.
Choisissez une API de suivi multitransporteur lorsque l’exigence principale est une expérience de suivi cohérente entre les transporteurs, les canaux ou les pays. Cela peut être utile aux équipes e-commerce qui souhaitent un modèle de statut post-achat commun sans créer d’analyseurs de suivi distincts pour chaque transporteur. Si vous avez besoin à la fois de la création d’étiquettes et du suivi, vérifiez si un même fournisseur prend en charge les deux ou prévoyez une architecture en deux parties.
Pour un nouveau projet, commencez par une petite preuve de concept. Testez une expédition nationale, une expédition internationale si nécessaire, une requête échouée, un événement d’exception et un scénario de retour ou d’annulation. Comparez les données renvoyées avec la page de suivi destinée aux clients du transporteur et avec vos attentes opérationnelles. Ce n’est qu’ensuite que vous devrez vous engager dans un déploiement plus large.
FAQ
Une API de transporteur peut-elle fournir les tarifs, les étiquettes et le suivi ?
Parfois, mais il ne faut pas le supposer. Ces fonctions peuvent être des produits distincts ou nécessiter des autorisations de compte différentes. Confirmez chaque fonctionnalité, chaque service, chaque pays et chaque exigence d’identifiant dans la documentation actuelle du transporteur.
Une API multitransporteur est-elle toujours meilleure qu’une intégration directe ?
Non. Une API multitransporteur peut réduire le travail d’ingénierie lorsque vous avez besoin de processus communs pour plusieurs transporteurs, mais une intégration directe peut offrir un meilleur accès aux fonctionnalités ou aux contrôles propres à un transporteur. Le meilleur choix dépend des fonctions nécessaires et du coût de maintenance que vous pouvez prendre en charge.
Ai-je besoin d’un compte transporteur pour utiliser une API d’expédition ?
Souvent, notamment pour la création d’étiquettes, les frais de port, la facturation ou les tarifs négociés. Les exigences varient selon le transporteur, le produit, le pays et le fournisseur. Confirmez les règles d’intégration commerciales et techniques avant de développer l’intégration.
Quelle est la différence entre les numéros de suivi et les identifiants d’expédition ?
Un numéro de suivi est l’identifiant utilisé pour suivre un colis dans le réseau d’un transporteur. Un identifiant d’expédition peut identifier une transaction, un groupe de colis, une demande d’étiquette ou un enregistrement interne. Une expédition peut contenir plusieurs colis ; votre modèle de données ne doit donc pas supposer qu’une commande correspond toujours à un seul numéro de suivi.
Comment une équipe doit-elle choisir entre UPS, FedEx, USPS et DHL ?
Commencez par les itinéraires, les services, les profils de colis, les conditions du compte et les fonctions d’API requises, plutôt que de choisir uniquement en fonction de la marque. Testez ensuite la documentation et les réponses réelles du transporteur pour vos scénarios nationaux et internationaux les plus courants.
