API de suivi FedEx : comment suivre des colis étape par étape

17TRACK2026-10-23 20:33

Pour suivre des colis FedEx via une application, créez un compte FedEx Developer, obtenez les identifiants API, demandez un jeton d’accès OAuth, envoyez une demande de suivi et intégrez la réponse à votre flux de commandes ou d’expéditions. La FedEx Tracking API est destinée aux systèmes logiciels qui ont besoin de données sur le statut des expéditions, tandis que le site Web de FedEx est généralement plus rapide pour vérifier manuellement un seul colis.

Fedex Tracking Api How to Track Packages Step by Step

Ce guide explique la séquence d’intégration, les informations à valider, les erreurs courantes de mise en œuvre et une alternative pour les entreprises qui ont besoin d’un suivi multi-transporteurs plutôt que d’une connectivité limitée à FedEx. Les champs exacts des requêtes, les règles d’authentification, les environnements et la disponibilité des services doivent toujours être confirmés dans la documentation FedEx actuelle avant le déploiement en production.

Choisissez d’abord la bonne méthode de suivi

La meilleure méthode dépend de la personne qui effectue l’action et du nombre d’expéditions à surveiller.

Recherche ponctuelle : Utilisez la page de suivi FedEx lorsqu’un client ou un agent du support doit seulement vérifier une seule expédition.
Application interne : Utilisez la FedEx Tracking API lorsqu’un système de gestion des commandes, une application d’entrepôt, un portail client ou un outil de support a besoin de données de statut programmatiques.
Opération multi-transporteurs : Envisagez une plateforme de suivi lorsque l’entreprise reçoit des expéditions de FedEx et d’autres transporteurs et souhaite disposer d’une intégration normalisée unique, d’un modèle de statut unique ou d’une expérience de suivi unique destinée aux clients.

Une intégration API limitée à FedEx peut fournir un contrôle direct et convenir à un système conçu autour des expéditions FedEx. Cela signifie également que votre équipe doit elle-même gérer l’authentification, les limites de requêtes, les changements de réponse, la logique de statut propre au transporteur, la gestion des erreurs et toute intégration supplémentaire avec d’autres transporteurs.

Ce dont vous avez besoin avant d’utiliser la FedEx Tracking API

Préparez les éléments suivants avant d’écrire l’intégration :

Un compte FedEx Developer et un accès au portail développeur FedEx.
Les identifiants API requis pour l’environnement FedEx sélectionné. La documentation FedEx peut faire référence à des identifiants tels qu’un identifiant client et un secret client.
Une relation de compte FedEx ou d’autres informations de compte si l’opération API sélectionnée l’exige.
Un emplacement sécurisé côté serveur pour les identifiants. N’exposez pas le secret client dans du JavaScript exécuté dans le navigateur, une application mobile ou un dépôt public.
Au moins un identifiant d’expédition valide pour les tests, tel qu’un numéro de suivi FedEx. Les données de test doivent représenter les types d’expéditions et les services que votre application traitera.
Un plan pour stocker le dernier statut connu, l’horodatage de l’événement, les informations de localisation et l’heure de la dernière vérification réussie.

FedEx sépare l’accès développeur, l’authentification, les environnements API et les exigences opérationnelles. Une connexion réussie au portail développeur ne prouve pas à elle seule qu’une requête de production est prête. Consultez la documentation produit actuelle pour connaître les prérequis du compte, les exigences d’approbation, les URL des environnements et les éventuelles restrictions d’utilisation.

Étape 1 : créer une application dans le portail développeur FedEx

Commencez par le FedEx Developer Portal officiel et identifiez le produit Track API. Créez ou sélectionnez une application, puis notez les identifiants fournis pour l’environnement que vous prévoyez d’utiliser. Séparez les identifiants de développement et de production.

À ce stade, confirmez quatre détails :

Quel produit API contient l’opération de suivi dont vous avez besoin.
Quelle URL de base correspond à l’environnement de test ou de production.
Quelle méthode d’authentification et quelles portées, le cas échéant, sont requises.
Si la requête nécessite un numéro de compte FedEx ou un autre champ lié au compte.

Ne copiez pas une URL ou un nom de champ provenant d’un ancien exemple de code sans vérifier la documentation actuelle. Les API des transporteurs peuvent modifier les versions des points de terminaison, les en-têtes obligatoires, les structures de réponse ou les règles d’intégration.

Étape 2 : demander un jeton d’accès OAuth

L’authentification des API FedEx utilise généralement les identifiants client OAuth 2.0. Votre application envoie ses identifiants client au point de terminaison d’autorisation FedEx et reçoit un jeton d’accès à courte durée de vie. L’application envoie ensuite ce jeton dans l’en-tête Authorization de la requête de suivi.

Un exemple simplifié en ligne de commande ressemble à ceci :

curl -X POST "<FEDEX_OAUTH_URL>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<CLIENT_ID>" \
  -d "client_secret=<CLIENT_SECRET>"

Considérez ceci comme un modèle de mise en œuvre et non comme un substitut à la documentation d’authentification FedEx actuelle. Le code de production doit lire la valeur d’expiration du jeton, mettre celui-ci en cache de manière sécurisée et en demander un nouveau lorsqu’il expire ou lorsque l’API renvoie une erreur d’authentification. Évitez de demander un nouveau jeton pour chaque numéro de suivi, sauf si les limites officielles et votre volume de trafic le rendent nécessaire.

Les mesures de sécurité utiles pour l’authentification comprennent :

Stocker les secrets dans un gestionnaire de secrets côté serveur ou dans des variables d’environnement protégées.
Ne jamais écrire les jetons d’accès ou les secrets clients dans les journaux de l’application.
Utiliser des identifiants distincts pour le développement et la production lorsque la plateforme permet cette séparation.
Renvoyer une erreur contrôlée à l’utilisateur en cas d’échec de l’authentification ; n’exposez pas la réponse brute du transporteur.
Surveiller séparément les échecs de jeton et les échecs liés aux numéros de suivi invalides.

Étape 3 : construire la requête de suivi

Après avoir obtenu un jeton valide, construisez la requête décrite dans la documentation actuelle de la FedEx Track API. La requête identifie généralement un ou plusieurs enregistrements d’expédition et peut inclure des options qui influencent le niveau de détail renvoyé. Les noms exacts des propriétés JSON et les champs obligatoires doivent provenir de la version du point de terminaison FedEx que vous utilisez.

Un modèle de requête représentatif peut ressembler à ceci :

curl -X POST "<FEDEX_TRACK_BASE_URL>/track/v1/trackingnumbers" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "trackingInfo": [
      {
        "trackingNumberInfo": {
          "trackingNumber": "<FEDEX_TRACKING_NUMBER>"
        }
      }
    ],
    "includeDetailedScans": true
  }'

Le chemin du point de terminaison et les noms de champs ci-dessus doivent être vérifiés dans la documentation FedEx en ligne avant utilisation. Certaines intégrations peuvent nécessiter une structure de requête différente, un numéro de compte, une recherche par référence ou une autre option pour les analyses détaillées. Ne supposez pas qu’un numéro de suivi appartenant à un autre transporteur peut être envoyé à un point de terminaison réservé à FedEx.

Étape 4 : convertir la réponse en champs métier

Ne transmettez pas directement la réponse complète du transporteur à une page destinée aux clients. Commencez par la convertir en un modèle interne stable. Un enregistrement d’expédition pratique peut inclure :

Transporteur : FedEx.
Identifiant de suivi : L’identifiant soumis à l’API.
Statut actuel : Votre statut normalisé, tel que étiquette créée, en transit, en cours de livraison, livré, exception ou inconnu.
Statut du transporteur : Le statut ou code FedEx d’origine, conservé pour le support et le débogage.
Dernier événement : La description et l’horodatage de l’événement le plus récent renvoyé par FedEx.
Livraison estimée : À stocker uniquement lorsque la réponse la fournit, et à afficher comme une estimation plutôt que comme une garantie.
Confirmation de livraison : Utilisez la réponse du transporteur pour déterminer si la livraison a été signalée.
Heure de la dernière vérification : L’horodatage enregistré par votre système, qui diffère de l’heure de l’événement indiquée par FedEx.

La normalisation des statuts nécessite un jugement éditorial et opérationnel. Par exemple, une exception ne doit pas être automatiquement affichée comme un échec de livraison, et un événement indiquant la création de l’étiquette ne signifie pas nécessairement que le colis circule dans le réseau. Conservez l’événement original du transporteur avec votre statut normalisé afin que le personnel du support puisse examiner les différences.

Étape 5 : gérer les erreurs et les informations incomplètes

Une intégration de suivi en production doit distinguer les différents types d’échec. Une requête mal formée, un jeton expiré, un numéro de suivi invalide, une panne temporaire du transporteur et une réponse réussie sans événement utile ne constituent pas la même situation.

Situation	Traitement recommandé
Échec de l’authentification	Actualisez les identifiants ou la gestion du jeton, puis alertez le responsable de l’intégration si le problème persiste.
Requête invalide	Validez la charge utile, les en-têtes obligatoires, le format de l’identifiant et l’environnement avant de réessayer.
Numéro de suivi introuvable	Affichez un état non résolu ou indisponible ; ne dites pas au client que le colis est perdu sans éléments supplémentaires.
Délai d’attente temporaire ou erreur serveur	Utilisez des tentatives limitées avec temporisation progressive et conservez le dernier statut connu.
Aucun scan récent	Affichez le dernier événement confirmé et son ancienneté au lieu d’inventer une localisation actuelle.

La logique de nouvelle tentative doit rester prudente. Des requêtes répétées peuvent augmenter la charge, générer des alertes excessives ou entrer en conflit avec les limites de l’API. Appliquez des délais d’expiration, une temporisation exponentielle, un traitement idempotent et une surveillance des échecs répétés. Les limites exactes de débit et les engagements de service doivent être tirés de votre accord FedEx ou de la documentation actuelle, et non supposés à partir d’une application exemple.

Étape 6 : planifier les mises à jour sans créer une mauvaise expérience client

La plupart des systèmes d’expédition n’ont pas besoin de demander un nouveau résultat toutes les quelques secondes. Utilisez une stratégie de mise à jour fondée sur l’état de l’expédition. Une nouvelle expédition peut nécessiter des vérifications plus fréquentes après la création de l’étiquette, tandis qu’une expédition livrée devrait normalement cesser d’être interrogée. Une exception peut nécessiter un flux de support distinct plutôt qu’une interrogation automatisée plus rapide.

Lorsque vous présentez les résultats aux clients, indiquez l’heure du dernier événement du transporteur et précisez si la date de livraison est estimée. Si l’API est temporairement indisponible, conservez le dernier résultat vérifié et expliquez que le statut n’a pas été actualisé. Cela est plus utile que de remplacer un statut connu par une erreur générique.

Étape 7 : tester l’ensemble du flux

Testez davantage qu’une réponse réussie. Un plan de test réaliste doit couvrir :

Un numéro de suivi valide avec plusieurs événements de scan.
Une expédition récemment créée avec un historique de suivi limité.
Une expédition livrée.
Une expédition faisant l’objet d’une exception ou d’un retard, si des données de test représentatives sont disponibles.
Un numéro de suivi invalide ou incomplet.
Un identifiant expiré ou révoqué.
Un délai d’attente, une réponse de limitation de débit et une erreur serveur temporaire.
Des événements en double et des événements reçus dans le désordre.
Différents fuseaux horaires et transitions vers ou depuis l’heure d’été.
La suppression des identifiants, jetons, données personnelles et charges utiles complètes du transporteur dans les journaux.

Avant la mise en production, comparez votre statut normalisé avec la page de suivi FedEx pour un échantillon contrôlé. Les deux affichages peuvent ne pas être actualisés exactement au même moment ; l’objectif est donc de confirmer que votre analyseur interprète correctement la réponse et ne transforme pas des données manquantes en affirmation définitive.

Quand une API de suivi multi-transporteurs est-elle plus adaptée ?

Une intégration directe avec FedEx est pertinente lorsque FedEx est le principal transporteur et que votre équipe souhaite gérer toute la logique de l’application. Elle est moins efficace lorsque les commandes peuvent transiter par plusieurs transporteurs, marketplaces, opérateurs postaux ou services de livraison régionaux. Dans ce cas, l’entreprise peut avoir besoin de la détection du transporteur, d’un modèle de statut commun, de l’orchestration de webhooks ou d’interrogations, de pages de suivi personnalisées et d’une vue unique pour le support.

17TRACK fournit une Tracking API distincte et publie sa documentation développeur à l’adresse api.17track.net. Elle peut être évaluée comme option multi-transporteurs lorsque le besoin dépasse le suivi limité à FedEx. Le bon choix dépend des transporteurs, des pays, du niveau de détail des événements, du modèle d’intégration, des conditions commerciales et des contrôles opérationnels que votre projet peut vérifier pendant les tests. Un service multi-transporteurs ne supprime pas la nécessité de tester les exceptions propres à chaque transporteur ni de valider l’exactitude et le délai des événements pour votre propre ensemble d’expéditions.

Liste de contrôle pratique pour la mise en œuvre

Confirmez que le produit API FedEx correspond au type de recherche dont vous avez besoin.
Vérifiez le point de terminaison d’authentification actuel, l’URL de base, le schéma de requête et les en-têtes obligatoires.
Conservez les secrets clients et les jetons d’accès sur le serveur.
Mettez les jetons OAuth en cache et actualisez-les de manière sécurisée.
Validez les identifiants de suivi avant d’envoyer les requêtes.
Stockez à la fois le statut original du transporteur et votre statut normalisé.
Enregistrez séparément l’heure de l’événement du transporteur et l’heure de récupération par votre système.
Utilisez des tentatives limitées et surveillez séparément les erreurs d’authentification, de validation, de délai d’attente et du transporteur.
Arrêtez les interrogations régulières après un état final, conformément à vos règles opérationnelles.
Testez les variations réelles des réponses avant d’exposer les messages de statut aux clients.
Revérifiez la documentation FedEx lors d’un changement de version d’API ou de l’extension aux types d’expédition.

FAQ

Puis-je utiliser le site Web de FedEx au lieu de l’API ?

Oui. Le site Web de FedEx est généralement l’option la plus simple pour une recherche manuelle. Une API devient utile lorsqu’un logiciel doit récupérer automatiquement les données de suivi, associer les événements de statut aux commandes ou présenter les informations de suivi dans une autre application.

Ai-je besoin d’un jeton OAuth pour chaque requête de suivi ?

En général, l’application obtient un jeton d’accès et l’envoie avec les requêtes API suivantes jusqu’à son expiration. Mettez le jeton en cache de manière sécurisée et suivez la documentation d’authentification FedEx actuelle concernant l’expiration et le renouvellement. N’exposez pas le jeton à un navigateur ou à un client.

L’API peut-elle me dire exactement où se trouve un colis ?

Elle peut renvoyer les événements de suivi et les autres informations fournies par FedEx pour l’expédition. Le résultat peut indiquer un lieu de scan ou une installation, mais ne doit pas être interprété comme une géolocalisation GPS continue en temps réel. Affichez uniquement la localisation et les détails d’événement effectivement renvoyés.

Pourquoi un numéro de suivi n’a-t-il parfois aucune mise à jour ?

Une expédition peut avoir été créée sans scan récent, l’identifiant peut être incorrect, l’événement peut ne pas être encore disponible dans la réponse ou le service du transporteur peut être temporairement indisponible. Conservez le dernier résultat confirmé, indiquez quand il a été vérifié et examinez les échecs répétés au lieu de déclarer l’expédition perdue.

Une entreprise de commerce électronique doit-elle créer des API distinctes pour chaque transporteur ?

Cela peut être raisonnable pour une activité principalement axée sur FedEx et disposant de solides ressources d’ingénierie. Une entreprise expédiant avec plusieurs transporteurs peut préférer une couche de suivi multi-transporteurs afin de réduire le travail d’intégration et de normaliser les événements. Comparez la couverture des transporteurs, le niveau de détail des données, la fiabilité, la documentation, le coût et le contrôle des expériences destinées aux clients avant de choisir.

Suivi des expéditions 17TRACK

Suivi de commandes de marque pour DTC optimisé par l’IA

17TRACK Order Tracking

17RETURNS

17TRACK API