Fedex Tracking Api: Pakketten stap voor stap volgen
Om FedEx-pakketten via een applicatie te volgen, maakt u een FedEx Developer-account aan, verkrijgt u API-inloggegevens, vraagt u een OAuth-toegangstoken aan, dient u een trackingverzoek in en verwerkt u het antwoord in uw order- of verzendworkflow. De FedEx Tracking API is bedoeld voor softwaresystemen die verzendstatusgegevens nodig hebben, terwijl de FedEx-website meestal sneller is voor het handmatig controleren van één pakket.
Deze handleiding legt de integratiestappen uit, de informatie die moet worden gevalideerd, veelvoorkomende implementatiefouten en een alternatief voor bedrijven die tracking voor meerdere vervoerders nodig hebben in plaats van alleen FedEx-connectiviteit. Exacte aanvraagvelden, authenticatieregels, omgevingen en beschikbaarheid van services moeten altijd vóór implementatie in productie worden gecontroleerd in de actuele FedEx-documentatie.
Kies eerst de juiste trackingmethode
De beste methode hangt ervan af wie actie onderneemt en hoeveel zendingen moeten worden gevolgd.
- Eenmalige controle: Gebruik de FedEx-trackingpagina wanneer een klant of supportmedewerker slechts één zending hoeft te controleren.
- Interne applicatie: Gebruik de FedEx Tracking API wanneer een orderbeheersysteem, magazijnapplicatie, klantportaal of supporttool programmatisch statusgegevens nodig heeft.
- Activiteiten met meerdere vervoerders: Overweeg een trackingplatform wanneer het bedrijf zendingen ontvangt van FedEx en andere vervoerders en één genormaliseerde integratie, één statusmodel of één klantgerichte trackingervaring wil.
Een API-integratie die alleen op FedEx is gericht, kan directe controle bieden en geschikt zijn voor een systeem dat rond FedEx-zendingen is gebouwd. Dit betekent ook dat uw team zelf authenticatie, aanvraaglimieten, wijzigingen in antwoorden, vervoerderspecifieke statuslogica, foutafhandeling en eventuele aanvullende vervo||||integraties moet beheren.
Wat u nodig hebt voordat u de FedEx Tracking API gebruikt
Bereid de volgende zaken voor voordat u de integratie schrijft:
- Een FedEx Developer-account en toegang tot het FedEx-ontwikkelaarsportaal.
- De API-inloggegevens die vereist zijn voor de geselecteerde FedEx-omgeving. In de FedEx-documentatie kan worden verwezen naar inloggegevens zoals een client-ID en clientgeheim.
- Een FedEx-accountrelatie of andere accountinformatie als de geselecteerde API-bewerking dit vereist.
- Een veilige serverlocatie voor inloggegevens. Stel het clientgeheim niet bloot in JavaScript in de browser, een mobiele applicatie of een openbare repository.
- Ten minste één geldige identificatie van een zending voor tests, zoals een FedEx-trackingnummer. Testgegevens moeten de typen zendingen en services vertegenwoordigen die uw applicatie zal verwerken.
- Een plan voor het opslaan van de laatst bekende status, het tijdstip van de gebeurtenis, locatiegegevens en het tijdstip van de laatste succesvolle controle.
FedEx maakt onderscheid tussen ontwikkelaarstoegang, authenticatie, API-omgevingen en operationele vereisten. Een geslaagde aanmelding bij het ontwikkelaarsportaal bewijst op zichzelf niet dat een productieaanvraag gereed is. Controleer de actuele productdocumentatie voor accountvereisten, goedkeuringsvereisten, omgevings-URL's en eventuele gebruiksbeperkingen.
Stap 1: Maak een applicatie aan in het FedEx-ontwikkelaarsportaal
Begin in het officiële FedEx Developer Portal en zoek het Track API-product. Maak een applicatie aan of selecteer er een en noteer vervolgens de inloggegevens voor de omgeving die u wilt gebruiken. Houd ontwikkelings- en productie-inloggegevens gescheiden.
Bevestig in deze fase vier details:
- Welk API-product de trackingbewerking bevat die u nodig hebt.
- Welke basis-URL bij de test- of productieomgeving hoort.
- Welke authenticatiemethode en eventuele scopes vereist zijn.
- Of voor de aanvraag een FedEx-accountnummer of een ander accountveld nodig is.
Kopieer geen URL of veldnaam uit een oud codevoorbeeld zonder de actuele documentatie te controleren. Carrier-API's kunnen endpointversies, verplichte headers, antwoordstructuren of onboardingregels wijzigen.
Stap 2: Vraag een OAuth-toegangstoken aan
FedEx API-authenticatie maakt doorgaans gebruik van OAuth 2.0-clientgegevens. Uw applicatie stuurt de clientgegevens naar het FedEx-autorisatie-endpoint en ontvangt een toegangstoken met een korte geldigheidsduur. Vervolgens stuurt de applicatie dit token mee in de Authorization-header van het trackingverzoek.
Een vereenvoudigd voorbeeld op de opdrachtregel ziet er als volgt uit:
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>"
Beschouw dit als een implementatiepatroon en niet als vervanging van de actuele FedEx-authenticatiedocumentatie. De productiecode moet de vervalwaarde van het token uitlezen, het token veilig cachen en een nieuw token aanvragen wanneer het verloopt of wanneer de API een authenticatiefout retourneert. Vraag niet voor elk trackingnummer een nieuw token aan, tenzij de officiële limieten en uw verkeerspatroon dit noodzakelijk maken.
Nuttige beveiligingsmaatregelen voor authenticatie zijn onder andere:
- Bewaar geheimen in een server-side secretsmanager of in beveiligde omgevingsvariabelen.
- Schrijf toegangstokens of clientgeheimen nooit naar applicatielogboeken.
- Gebruik afzonderlijke inloggegevens voor ontwikkeling en productie wanneer het platform die scheiding ondersteunt.
- Geef de gebruiker een gecontroleerde foutmelding wanneer authenticatie mislukt; stel het onbewerkte antwoord van de vervoerder niet bloot.
- Monitor tokenfouten afzonderlijk van fouten met ongeldige trackingnummers.
Stap 3: Bouw het trackingverzoek
Stel na het verkrijgen van een geldig token het verzoek samen dat in de actuele FedEx Track API-documentatie wordt beschreven. Het verzoek identificeert doorgaans een of meer zendingen en kan opties bevatten die bepalen hoeveel details worden geretourneerd. De exacte JSON-eigenschapsnamen en verplichte velden moeten afkomstig zijn uit de versie van het FedEx-endpoint die u gebruikt.
Een representatief verzoekpatroon kan er als volgt uitzien:
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
}'
Het bovenstaande endpointpad en de veldnamen moeten vóór gebruik worden gecontroleerd aan de hand van de actuele FedEx-documentatie. Sommige integraties hebben mogelijk een andere verzoekstructuur, een accountnummer, een op referentie gebaseerde zoekopdracht of een andere optie voor gedetailleerde scans nodig. Ga er niet van uit dat een trackingnummer van een andere vervoerder naar een uitsluitend op FedEx gericht endpoint kan worden gestuurd.
Stap 4: Verwerk het antwoord in bedrijfsvelden
Stuur het volledige antwoord van de vervoerder niet rechtstreeks door naar een klantgerichte pagina. Zet het eerst om in een stabiel intern model. Een praktisch zendingrecord kan het volgende bevatten:
- Vervoerder: FedEx.
- Trackingidentificatie: De identificatie die naar de API is verzonden.
- Huidige status: Uw genormaliseerde status, zoals label aangemaakt, onderweg, uit voor bezorging, bezorgd, uitzondering of onbekend.
- Status van de vervoerder: De oorspronkelijke FedEx-status of -code, bewaard voor support en foutopsporing.
- Laatste gebeurtenis: De meest recente gebeurtenisbeschrijving en het tijdstip dat door FedEx zijn geretourneerd.
- Geschatte bezorging: Sla deze alleen op wanneer het antwoord deze informatie bevat en toon deze als een schatting, niet als een garantie.
- Bezorgbevestiging: Gebruik het antwoord van de vervoerder om te bepalen of de bezorging is gemeld.
- Tijdstip van laatste controle: Het tijdstip dat door uw systeem is geregistreerd, wat verschilt van het tijdstip van de gebeurtenis dat door FedEx is gemeld.
Het normaliseren van statussen vereist redactioneel en operationeel inzicht. Een uitzondering moet bijvoorbeeld niet automatisch worden weergegeven als een mislukte bezorging, en een gebeurtenis waarbij alleen een label is aangemaakt betekent niet noodzakelijk dat het pakket door het netwerk beweegt. Bewaar de oorspronkelijke gebeurtenis van de vervoerder naast uw genormaliseerde status, zodat supportmedewerkers verschillen kunnen onderzoeken.
Stap 5: Verwerk fouten en onvolledige informatie
Een trackingintegratie voor productie moet onderscheid maken tussen verschillende fouttypen. Een verkeerd samengesteld verzoek, een verlopen token, een ongeldig trackingnummer, een tijdelijke storing bij de vervoerder en een geslaagd antwoord zonder bruikbare gebeurtenis zijn niet dezelfde situatie.
| Situatie | Aanbevolen afhandeling |
|---|---|
| Authenticatiefout | Vernieuw de inloggegevens of tokenafhandeling en waarschuw de eigenaar van de integratie als het probleem aanhoudt. |
| Ongeldig verzoek | Valideer de payload, verplichte headers, indeling van de identificatie en omgeving voordat u opnieuw probeert. |
| Trackingnummer niet gevonden | Toon een status voor onopgelost of niet beschikbaar; vertel de klant niet dat het pakket verloren is zonder aanvullend bewijs. |
| Tijdelijke time-out of serverfout | Gebruik een beperkt aantal pogingen met back-off en behoud de laatst bekende status. |
| Geen recente scan | Toon de laatste bevestigde gebeurtenis en hoe oud deze is, in plaats van een actuele locatie te verzinnen. |
Wees terughoudend met retrylogica. Herhaalde verzoeken kunnen de belasting verhogen, luidruchtige waarschuwingen veroorzaken of in strijd zijn met API-limieten. Pas time-outs, exponentiële back-off, idempotente verwerking en monitoring van herhaalde fouten toe. De exacte snelheidslimieten en serviceverplichtingen moeten uit uw FedEx-overeenkomst of de actuele documentatie komen en niet op basis van een voorbeeldapplicatie worden aangenomen.
Stap 6: Plan updates zonder een slechte klantervaring te creëren
De meeste verzendsystemen hoeven niet elke paar seconden een nieuw resultaat op te vragen. Gebruik een updatestrategie die is gebaseerd op de status van de zending. Een nieuwe zending heeft na het aanmaken van het label mogelijk vaker controles nodig, terwijl een bezorgde zending normaal gesproken niet meer moet worden gepolld. Voor een uitzondering kan een afzonderlijke supportworkflow nodig zijn in plaats van sneller automatisch pollen.
Vermeld bij het presenteren van resultaten aan klanten het tijdstip van de laatste gebeurtenis van de vervoerder en maak duidelijk of een bezorgdatum wordt geschat. Als de API tijdelijk niet beschikbaar is, behoud dan het laatste geverifieerde resultaat en leg uit dat de status niet is vernieuwd. Dit is nuttiger dan een bekende status vervangen door een algemene fout.
Stap 7: Test de volledige workflow
Test meer dan alleen een geslaagd antwoord. Een realistisch testplan moet het volgende omvatten:
- Een geldig trackingnummer met meerdere scan-gebeurtenissen.
- Een pas aangemaakte zending met een beperkte trackinggeschiedenis.
- Een bezorgde zending.
- Een uitzondering of vertraagde zending, als representatieve testgegevens beschikbaar zijn.
- Een ongeldig of onvolledig trackingnummer.
- Een verlopen of ingetrokken inloggegeven.
- Een time-out, een antwoord wegens een snelheidslimiet en een tijdelijke serverfout.
- Dubbele gebeurtenissen en gebeurtenissen die niet in de juiste volgorde binnenkomen.
- Verschillende tijdzones en overgangen naar zomertijd.
- Het maskeren van inloggegevens, tokens, persoonsgegevens en volledige payloads van vervoerders in logboeken.
Vergelijk vóór ingebruikname uw genormaliseerde status met de FedEx-trackingpagina voor een gecontroleerde steekproef. De twee weergaven worden mogelijk niet exact op hetzelfde moment bijgewerkt. Het doel is daarom te bevestigen dat uw parser het antwoord correct interpreteert en ontbrekende gegevens niet omzet in een definitieve bewering.
Wanneer een tracking-API voor meerdere vervoerders beter past
Een directe FedEx-integratie is logisch wanneer FedEx de belangrijkste vervoerder is en uw team de volledige applicatielogica zelf wil beheren. Deze aanpak is minder efficiënt wanneer orders via meerdere vervoerders, marktplaatsen, postbedrijven of regionale bezorgdiensten kunnen worden verzonden. In die situatie heeft het bedrijf mogelijk vervoerdersdetectie, een gemeenschappelijk statusmodel, orkestratie via webhooks of polling, merkgerichte trackingpagina's en één supportweergave nodig.
17TRACK biedt een afzonderlijke Tracking API en publiceert ontwikkelaarsdocumentatie op api.17track.net. Dit kan worden geëvalueerd als optie voor meerdere vervoerders wanneer de vereiste breder is dan tracking die alleen op FedEx is gericht. De juiste keuze hangt af van de vervoerders, landen, gebeurtenisdetails, het integratiemodel, commerciële voorwaarden en operationele controles die uw project tijdens het testen kan verifiëren. Een dienst voor meerdere vervoerders neemt niet de noodzaak weg om vervoerderspecifieke uitzonderingen te testen of de nauwkeurigheid en timing van gebeurtenissen voor uw eigen zendingen te valideren.
Praktische implementatiechecklist
- Bevestig dat het FedEx API-product overeenkomt met het type zoekopdracht dat u nodig hebt.
- Controleer het actuele authenticatie-endpoint, de basis-URL, het aanvraagschema en de verplichte headers.
- Houd clientgeheimen en toegangstokens op de server.
- Cache OAuth-tokens veilig en vernieuw ze op veilige wijze.
- Valideer trackingidentificaties voordat u verzoeken verzendt.
- Sla zowel de oorspronkelijke status van de vervoerder als uw genormaliseerde status op.
- Registreer het tijdstip van de gebeurtenis bij de vervoerder afzonderlijk van het ophaaltijdstip van uw systeem.
- Gebruik een beperkt aantal pogingen en monitor authenticatie-, validatie-, time-out- en vervoerdersfouten afzonderlijk.
- Stop met routinematig pollen na een eindstatus, afhankelijk van uw operationele regels.
- Test echte variaties in antwoorden voordat u statusberichten aan klanten toont.
- Controleer de FedEx-documentatie opnieuw wanneer u API-versies wijzigt of de typen zendingen uitbreidt.
Veelgestelde vragen
Kan ik de FedEx-website gebruiken in plaats van de API?
Ja. De FedEx-website is doorgaans de eenvoudigste optie voor een handmatige controle. Een API wordt nuttig wanneer software trackinggegevens automatisch moet ophalen, statusgebeurtenissen aan orders moet koppelen of trackinginformatie in een andere applicatie moet tonen.
Heb ik voor elk trackingverzoek een OAuth-token nodig?
Doorgaans verkrijgt de applicatie een toegangstoken en stuurt zij dit mee met volgende API-verzoeken totdat het verloopt. Cache het token veilig en volg de actuele FedEx-authenticatiedocumentatie voor het gedrag rond verval en vernieuwen. Stel het token niet bloot aan een browser of klant.
Kan de API mij precies vertellen waar een pakket zich bevindt?
De API kan de trackinggebeurtenissen en andere informatie retourneren die FedEx voor de zending verstrekt. Het resultaat kan een scanlocatie of faciliteit tonen, maar mag niet worden geïnterpreteerd als continue realtime GPS-positionering. Toon alleen de locatie en gebeurtenisdetails die daadwerkelijk worden geretourneerd.
Waarom heeft een trackingnummer soms geen update?
Een zending kan zijn aangemaakt zonder recente scan, de identificatie kan onjuist zijn, de gebeurtenis is mogelijk nog niet beschikbaar in het antwoord of de service van de vervoerder kan tijdelijk niet beschikbaar zijn. Behoud het laatste bevestigde resultaat, toon wanneer dit is gecontroleerd en onderzoek herhaalde fouten in plaats van de zending verloren te verklaren.
Moet een e-commercebedrijf afzonderlijke API's voor elke vervoerder bouwen?
Dat kan redelijk zijn voor een FedEx-gerichte activiteit met sterke technische middelen. Een bedrijf dat via meerdere vervoerders verzendt, geeft mogelijk de voorkeur aan een trackinglaag voor meerdere vervoerders om integratiewerk te beperken en gebeurtenissen te normaliseren. Vergelijk vervoerdersdekking, informatiedetail, betrouwbaarheid, documentatie, kosten en controle over klantgerichte ervaringen voordat u een keuze maakt.


