Verzendvervoerders-API's uitgelegd: UPS, FedEx, USPS, DHL en meer
API's van vervoerders zijn softwareverbindingen waarmee een winkel, magazijnsysteem, orderbeheerplatform of klantenservicetool verzendgegevens kan uitwisselen met vervoerders zoals UPS, FedEx, USPS en DHL. Ze kunnen taken ondersteunen zoals tariefaanvragen, het aanmaken van labels, het boeken van zendingen, trackingupdates, adrescontroles en meldingen over bezorgingsgebeurtenissen. De juiste API-aanpak hangt minder af van de naam van de vervoerder dan van de workflow die u wilt automatiseren, de landen die u bedient en de systemen die u al gebruikt.
Een integratie met één vervoerder kan goed werken wanneer uw verzendvolume en servicegebied voorspelbaar zijn. Een API voor meerdere vervoerders is meestal praktischer wanneer een organisatie diensten vergelijkt, internationaal verzendt of één trackingindeling voor meerdere vervoerders nodig heeft. Deze gids legt de belangrijkste API-typen uit, hoe de grote vervoerders op hoofdlijnen van elkaar verschillen en wat u moet controleren voordat u een integratie bouwt of aanschaft.
Wat een API van een vervoerder doet
Een API, oftewel application programming interface, definieert hoe twee softwaresystemen verzoeken en antwoorden uitwisselen. Bij verzending kan uw applicatie pakketgegevens, adressen van herkomst en bestemming, servicevoorkeuren en douane-informatie verzenden. De vervoerder of het verzendplatform retourneert vervolgens bijvoorbeeld een verzendtarief, labelgegevens, een trackingnummer of een foutmelding.
API's van vervoerders hebben doorgaans verschillende afzonderlijke functies:
- Tariefberekening: Vraagt een geschatte of contractuele verzendkosten aan voor een pakket en service.
- Aanmaken van zendingen: Verzendt verzendgegevens en ontvangt een trackingnummer of verzendbevestiging.
- Labelgeneratie: Genereert een afdrukbaar label, vaak als PDF, afbeelding of documentpayload.
- Tracking: Haalt verzendgebeurtenissen, statussen, locaties en bezorginformatie op wanneer deze beschikbaar zijn.
- Adresdiensten: Valideert, standaardiseert of vult adresgegevens aan, afhankelijk van de vervoerder en bestemming.
- Ophalen en manifesteren: Ondersteunt ophaalverzoeken of verzenddocumentatie aan het einde van de dag wanneer de account en service dit toestaan.
- Meldingen: Levert statusinformatie via polling, webhooks, e-mailfuncties of een ander gebeurtenismechanisme.
Deze mogelijkheden zijn niet automatisch opgenomen in elke API-account van een vervoerder. Een vervoerder kan diensten over verschillende producten verdelen, accountgoedkeuring vereisen of toegang beperken op basis van land, servicetype, klantovereenkomst of technische omgeving. Beschouw elke mogelijkheid als iets dat u moet bevestigen in de actuele documentatie van de vervoerder, niet als iets dat u kunt afleiden uit het bestaan van een API.
Directe API's van vervoerders versus API's voor meerdere vervoerders
Er zijn twee praktische integratiemodellen. Een directe integratie met een vervoerder verbindt uw software met het ontwikkelaarsplatform van één vervoerder. Een integratie voor meerdere vervoerders verbindt uw software met een tussenpartij die meerdere vervoerders normaliseert achter één interface.
| Model | Voordelen | Afwegingen | Meest geschikt voor |
|---|---|---|---|
| Directe API van een vervoerder | Directe toegang tot de eigen diensten, accountregels en verzendgegevens van de vervoerder | Afzonderlijke inloggegevens, indelingen, tests, foutafhandeling en onderhoud voor elke vervoerder | Een bedrijf met één primaire vervoerder of een gespecialiseerde vervoersworkflow |
| API voor meerdere vervoerders | Één integratie kan tracking, vervoerdersselectie en genormaliseerde statusverwerking vereenvoudigen | Dekking, functiediepte, accountvereisten en commerciële voorwaarden verschillen per aanbieder | E-commerce met meerdere vervoerders, marketplaces, 3PL's en grensoverschrijdende activiteiten |
Een API voor meerdere vervoerders vervangt niet noodzakelijkerwijs een directe relatie met een vervoerder. Voor sommige verzendfuncties kan nog steeds een vervoerdersaccount, onderhandelde tarieven, goedkeuring of directe configuratie vereist zijn. Het is ook belangrijk om te controleren of de tussenpartij labels aanmaakt, alleen bestaande zendingen volgt of beide ondersteunt.
Vergelijking van de API's van de belangrijkste vervoerders
UPS API
UPS biedt ontwikkelaarsresources voor het verbinden van bedrijfsapplicaties met UPS-diensten. Afhankelijk van de account, regio en het product kunnen ontwikkelaars mogelijkheden onderzoeken zoals tariefberekening, verzending, tracking, adresgerelateerde diensten en ophaalworkflows via de officiële UPS-ontwikkelaarsomgeving.
UPS wordt vaak overwogen door bedrijven met een omvangrijke pakketverwerking, die toegang tot specifieke UPS-diensten nodig hebben of al een UPS-account en contract beheren. De praktische vraag is niet alleen of UPS een API heeft. Het gaat erom of de specifieke UPS-service, factureringsregeling, bestemming en het pakketprofiel kunnen worden gebruikt via het API-product dat voor uw account beschikbaar is.
Bevestig vóór de implementatie het actuele authenticatieproces, de beschikbaarheid van een sandbox, ondersteunde aanvraagindelingen, de labeluitvoer, tariefgeschiktheid, het gedrag van trackinggebeurtenissen en migratievereisten. UPS-documentatie en productnamen kunnen veranderen, dus gebruik het officiële UPS-ontwikkelaarsportaal als uitgangspunt.
FedEx API
FedEx biedt een ontwikkelaarsplatform voor applicaties die met verzend- en bezorgdiensten van FedEx moeten werken. De documentatie is de aangewezen bron om beschikbare API's, inloggegevens, testomgevingen, verzendworkflows, tracking en servicespecifieke vereisten te controleren.
FedEx kan goed passen wanneer een organisatie afhankelijk is van FedEx-diensten of vervoerderspecifieke controle over verzend- en trackingworkflows nodig heeft. De integratie kan meer omvatten dan het verzenden van een adres en ontvangen van een label. Pakketafmetingen, serviceselectie, accountgegevens, douane-informatie, regels voor gevaarlijke goederen en internationale documentatie kunnen de aanvraag en het antwoord beïnvloeden.
Teams moeten zowel geslaagde als mislukte aanvragen testen. Een applicatie moet bijvoorbeeld weten hoe om te gaan met een ongeldig adres, een niet-ondersteunde service, een dubbele verzendaanvraag, een ontbrekend douaneveld en een tijdelijke storing bij de vervoerder. Raadpleeg het FedEx Developer Portal voor actuele documentatie en toegangsvereisten.
USPS API
USPS biedt online bedrijfs- en ontwikkelaarsresources voor applicaties die USPS-diensten gebruiken. USPS is vooral relevant voor binnenlandse pakket- en postworkflows in de VS, terwijl de exacte API-producten en toegangsvoorwaarden moeten worden gecontroleerd aan de hand van de actuele officiële documentatie.
USPS-integraties vereisen zorgvuldige tests, omdat een bedrijf mogelijk onderscheid moet maken tussen postproducten, pakketdiensten, trackinggebeurtenissen, adresgegevens en workflows voor labels of frankering. Een vereiste die alleen tracking betreft, verschilt wezenlijk van een applicatie die frankering moet kopen of verzendlabels moet genereren.
Ga er niet van uit dat een USPS API dezelfde aanvraagstructuur, gebeurteniswoordenschat, servicebeschikbaarheid of accountmodel heeft als UPS of FedEx. Bekijk de USPS-ontwikkelaarsresources en bevestig welke producten beschikbaar zijn voor uw gebruikssituatie, geografische bereik en accountregeling. Als uw bedrijf alleen een consistente trackingweergave voor meerdere vervoerders nodig heeft, kan een API voor meerdere vervoerders die op tracking is gericht minder aangepaste vervoerderslogica vereisen dan verschillende directe integraties.
DHL API
DHL is een groep bedrijven met verschillende logistieke en pakketdiensten. Daarom is “de DHL API” geen universeel product voor elke zending. De ontwikkelaarsresources van DHL omvatten API's en tools die bij de diensten horen, maar het relevante product hangt af van de DHL-bedrijfseenheid, bestemming, het type zending en de accountrelatie.
DHL is een logische keuze voor internationaal transport, expresdiensten en grensoverschrijdende activiteiten, maar de juiste integratie moet nog steeds worden afgestemd op de dienst die wordt aangeschaft. Controleer voordat u de workflow ontwerpt of de documentatie betrekking heeft op DHL Express, e-commercepakketdiensten, vracht of een ander DHL-aanbod.
Controleer ondersteunde landen, douane- en handelsfactuurvelden, servicecodes, trackinggedrag, labelformaten en vereisten voor het aanmaken van een account in het DHL Developer Portal. Neem voor internationale implementaties een proces op voor het afhandelen van douane-uitzonderingen en onvolledige documentatie, in plaats van tracking als de volledige levenscyclus van een zending te beschouwen.
Andere vervoerders
Bedrijven kunnen ook regionale of nationale vervoerders nodig hebben, zoals Canada Post, Royal Mail, Australia Post, DPD, GLS of Japan Post. Hun API's verschillen wat betreft dekking, onboarding, servicenamen, details van trackinggebeurtenissen, labelformaten en ondersteuning voor internationale zendingen. “Meer vervoerders” is daarom niet automatisch beter. De dekking moet worden gemeten aan de hand van de routes, diensten en verzendtypen die u daadwerkelijk gebruikt.
Bekijk voor een vervoerder die belangrijk is voor uw organisatie eerst de eigen ontwikkelaarsdocumentatie. Als de vervoerder via een platform van derden wordt ondersteund, controleer dan of de integratie direct is, of u uw eigen vervoerdersinloggegevens verstrekt en welke functies beschikbaar zijn. Ondersteuning voor tracking bewijst niet dat tariefberekening, het aanmaken van labels of het annuleren van zendingen ook wordt ondersteund.
Tracking-API of volledige verzend-API?
Veel projecten gebruiken de term “verzend-API” terwijl ze in werkelijkheid tracking van zendingen nodig hebben. Dit zijn verschillende scopes. Een tracking-API accepteert doorgaans een trackingnummer en vervoerder en retourneert vervolgens genormaliseerde gebeurtenissen of een actuele status. Een volledige verzend-API kan tarieven, labels, het aanmaken van zendingen, douanedocumenten en tracking omvatten.
Als uw belangrijkste doel is om de voortgang van een levering weer te geven op een e-commercesite, klantenportaal of supporttool, kan een trackinggerichte integratie voldoende zijn. De Tracking API van 17TRACK is een voorbeeld van een trackingproduct voor meerdere vervoerders; gebruik de documentatie ervan om de actuele vervoerdersdekking, aanvraagindelingen, authenticatie en het gedrag van gebeurtenissen te controleren voordat u het product invoert.
Als u frankering moet kopen of labels moet aanmaken, zal tracking alleen de workflow niet voltooien. Mogelijk hebt u directe vervoerdersaccounts, een verzendplatform of een verzend-API voor meerdere vervoerders met gedocumenteerde labelfunctionaliteit nodig. Door deze vereisten vroeg te scheiden, voorkomt u een veelgemaakte implementatiefout: een trackingproduct selecteren en later ontdekken dat het de zending die uw magazijn nodig heeft niet kan aanmaken.
Wat u moet controleren voordat u een API kiest
1. Definieer de bedrijfsworkflow
Schrijf de exacte actie op die het systeem moet uitvoeren. Voorbeelden zijn “trackinggebeurtenissen tonen nadat een bestelling is verzonden”, “de laagste in aanmerking komende service selecteren”, “een label in het magazijn aanmaken” of “een klant informeren wanneer de levering vertraging heeft”. Elke actie heeft andere gegevens, foutafhandeling en operationele vereisten.
2. Koppel vervoerders aan routes en diensten
Noteer landen van herkomst, landen van bestemming, pakkettypen, serviceniveaus, retourstromen en eventuele beperkte goederen. Een vervoerder kan technisch worden ondersteund en toch ongeschikt zijn voor een bepaalde route of service. Neem voor internationale zendingen douanegegevens, invoerrechten, belastingen en handelsdocumentatie op in de vereisten.
3. Bevestig toegangs- en commerciële voorwaarden
Controleer of de API een vervoerdersaccount, factureringsconfiguratie, goedkeuring, onderhandelde tarieven, een applicatietoken of een productiereview vereist. Testgegevens en productiegegevens kunnen verschillen. Plaats productiesecrets nooit in browsercode of openbare repositories; gebruik een veilige server-side integratie en roteer inloggegevens volgens uw beveiligingsbeleid.
4. Vergelijk de gegevenskwaliteit, niet alleen het aantal endpoints
Vraag hoe de API verzendstatus, verwachte levering, bezorgingsuitzonderingen, ontvangstbewijs, scans, retouren en zendingen met meerdere pakketten weergeeft. Een lange lijst met endpoints garandeert geen bruikbare details van gebeurtenissen. Bepaal hoe uw applicatie statussen zoals label aangemaakt, onderweg, uit voor bezorging, bezorgd, uitzondering en geretourneerd normaliseert.
5. Test scenario's met fouten en wijzigingen
Een productieklare integratie moet omgaan met time-outs, snelheidslimieten, dubbele aanvragen, ongeldige adressen, ontbrekende scans, storingen bij vervoerders, gewijzigde trackingnummers en late of niet-volgordelijke gebeurtenissen. Gebruik idempotentie wanneer de API dit ondersteunt, leg aanvraag-ID's vast en zorg dat herhalingen veilig zijn. Trackingsystemen moeten ook perioden zonder nieuwe scan kunnen verdragen, in plaats van elke stille periode als een fout te beschouwen.
6. Beoordeel de onderhoudskosten
API's van vervoerders veranderen. Versie-updates, certificaatwijzigingen, wijzigingen in servicecodes, nieuwe douanevelden en beëindigde endpoints kunnen de activiteiten beïnvloeden. Vraag wie wijzigingen in de documentatie bewaakt, wie verantwoordelijk is voor incidentrespons en hoe snel de integratie kan worden bijgewerkt. Een aanbieder voor meerdere vervoerders kan het aantal integraties dat uw team onderhoudt verminderen, maar introduceert een afhankelijkheid die moet worden beoordeeld op bedrijfscontinuïteit en ondersteuningskwaliteit.
Een praktisch besliskader
Kies een directe API van een vervoerder wanneer één vervoerder het grootste deel van uw zendingen verwerkt, u vervoerderspecifieke functies nodig hebt en uw team de integratie kan onderhouden. Kies een verzend-API voor meerdere vervoerders wanneer u tarieven, labels en het aanmaken van zendingen voor meerdere vervoerders via één workflow nodig hebt, op voorwaarde dat de vereiste diensten daadwerkelijk worden ondersteund.
Kies een tracking-API voor meerdere vervoerders wanneer de belangrijkste vereiste een consistente trackingervaring voor verschillende vervoerders, kanalen of landen is. Dit kan nuttig zijn voor e-commerceteams die één gedeeld statusmodel na aankoop willen zonder voor elke vervoerder afzonderlijke trackingparsers te bouwen. Als u zowel labels wilt aanmaken als tracking nodig hebt, controleer dan of één aanbieder beide ondersteunt of plan een architectuur in twee delen.
Begin voor een nieuw project met een kleinschalige proof of concept. Test één binnenlandse zending, indien relevant één internationale zending, een mislukte aanvraag, een uitzonderingsgebeurtenis en een retour- of annuleringsscenario. Vergelijk de geretourneerde gegevens met de trackingpagina van de vervoerder voor klanten en met uw operationele verwachtingen. Pas daarna moet u zich vastleggen op een bredere uitrol.
Veelgestelde vragen
Kan één API van een vervoerder tarieven, labels en tracking leveren?
Soms, maar dit mag niet worden aangenomen. Deze functies kunnen afzonderlijke producten zijn of verschillende accountrechten vereisen. Bevestig elke mogelijkheid, service, elk land en elke vereiste voor inloggegevens in de actuele documentatie van de vervoerder.
Is een API voor meerdere vervoerders altijd beter dan een directe integratie?
Nee. Een API voor meerdere vervoerders kan de ontwikkelingsinspanningen verminderen wanneer u gemeenschappelijke workflows voor verschillende vervoerders nodig hebt, maar een directe integratie kan betere toegang bieden tot vervoerderspecifieke functies of accountbeheer. De betere keuze hangt af van de functies die u nodig hebt en de onderhoudskosten die u kunt dragen.
Heb ik een vervoerdersaccount nodig om een verzend-API te gebruiken?
Vaak wel, vooral voor het aanmaken van labels, frankering, facturering of onderhandelde tarieven. De vereisten verschillen per vervoerder, product, land en aanbieder. Bevestig de commerciële en technische onboardingregels voordat u de integratie bouwt.
Wat is het verschil tussen trackingnummers en verzend-ID's?
Een trackingnummer is de identificatie die wordt gebruikt om een pakket door het netwerk van een vervoerder te volgen. Een verzend-ID kan een transactie, pakketgroep, labelaanvraag of intern record identificeren. Eén zending kan meerdere pakketten bevatten. Uw datamodel moet er daarom niet van uitgaan dat één bestelling altijd gelijkstaat aan één trackingnummer.
Hoe moet een team kiezen tussen UPS, FedEx, USPS en DHL?
Begin met de routes, diensten, pakketprofielen, accountvoorwaarden en vereiste API-functies in plaats van alleen op basis van het merk te kiezen. Test vervolgens de documentatie en daadwerkelijke antwoorden van de vervoerder voor uw meest voorkomende binnenlandse en internationale scenario's.
