Så här förenar du spårning av försändelser i Australien och Nya Zeeland med ett enda API

För att förena leveransspårning i Australien och Nya Zeeland med ett enda API ansluter du ditt order- eller orderhanteringssystem till en spårningstjänst för flera transportörer, registrerar varje försändelse med rätt transportörsidentitet och översätter inkommande spårningsuppdateringar till en konsekvent intern händelsemodell. Integrationen bör bevara transportörsspecifika detaljer och samtidigt ge ditt driftteam och dina kunder en enhetlig spårningsupplevelse för både inhemska och gränsöverskridande leveranser mellan Australien och Nya Zeeland.

För utvecklare, e-handelsansvariga och logistikteam är den största utmaningen inte att göra den första API-begäran. Det handlar om att hålla försändelseidentiteter, leveransstatusar, överlämningar mellan transportörer och kundaviseringar konsekventa när olika transportörer beskriver samma resa på olika sätt. Den här guiden förklarar hur du utformar integrationen, utvärderar ett spårnings-API och testar det innan du förlitar dig på det i produktion.

17TRACK API

Förenkla global paketspårning med leveransuppdateringar från över 3 500 transportörer.

Läs mer Relaterad artikel: Bästa programvaran för leveransspårning för e-handels- och logistikteam

Definiera vad det gemensamma API:t behöver förena

Ett gemensamt API ger din applikation en gemensam integrationspunkt. Det innebär inte att alla transportörer publicerar identisk information eller skannar paket med samma frekvens. Din arkitektur måste skilja mellan ett konsekvent gränssnitt och fullständig insyn.

Börja med en försändelseinventering baserad på faktisk orderhantering, snarare än en generell lista över transportörer som verkar i något av länderna. Ta med inhemska försändelser i Australien, inhemska försändelser i Nya Zeeland samt gränsöverskridande transporter i båda riktningarna. Lägg till andra ursprungsländer om de ingår i din verksamhet.

• Transportör och tjänst: Registrera transportören, den använda tjänsten och eventuella kända leveranspartner.
• Rutt: Skilj försändelsens ursprung och destination från platsen för den senaste skanningen.
• Identifierare: Registrera orderreferens, orderhanteringsreferens, spårningsnummer samt eventuella ersättnings- eller partnernummer.
• Operativt syfte: Ange om uppdateringarna stöder kundspårning, hantering av undantag, leveransbekräftelse eller alla tre.
• Nödvändig detaljnivå: Avgör om en övergripande leveransstatus räcker eller om agenter även behöver skanningsbeskrivningar, platser och tidsstämplar.

Denna inventering blir din checklista för godkännande. En leverantörs allmänna täckning av transportörer är användbar när du väljer kandidater, men beslutet bör baseras på om dina faktiska kombinationer av transportörer och tjänster returnerar användbar spårningsinformation.

Lösning för varumärkesanpassad orderspårning

Ge en bättre kundupplevelse och öka antalet återkommande köp med varumärkesanpassad spårning och automatiska aviseringar.

Prova gratis

Utvärdera spårnings-API:t utifrån din försändelsemix

17TRACK erbjuder ett Tracking API, vilket gör det till ett relevant alternativ att utvärdera för en integration med flera transportörer. Använd dess officiella API-dokumentation för att kontrollera aktuella integrationskrav. Betrakta stöd för transportörer, händelsefält, uppdateringsbeteende, kontobegränsningar och kommersiella villkor som sådant som måste verifieras för din implementation, inte som antaganden baserade på produktkategorin.

Fortsätt läsa: Spårning med flera transportörer: vad det är, fördelar och hur det fungerar

Ställ samma praktiska frågor om alla API:er du överväger:

• Kan det identifiera och spåra transportörerna och tjänsterna i din försändelseinventering?
• När transportörsidentifieringen är oklar, kan du ange en uttrycklig transportörsidentifierare?
• Hur tar din applikation emot uppdateringar och vilken återställningsmekanism finns om en uppdatering missas?
• Vilka ursprungliga transportörsdetaljer finns kvar tillsammans med normaliserade statusar?
• Vad händer när ett spårningsnummer är ogiltigt, ännu inte identifierat eller kopplat till mer än en möjlig transportör?
• Hur definieras användning, fakturering, spårningsperiod och åtkomstbegränsningar för ditt konto?

Rekommenderad beslutsregel: välj baserat på lyckade tester av dina verkliga leveransmönster, inte på det högsta angivna antalet transportörer. En integration är lämplig när den tillhandahåller tillräckligt med information för att stödja dina operativa beslut och visar fel tillräckligt tydligt för att du ska kunna återhämta dig från dem.

Bygg en intern modell som klarar skillnader mellan transportörer

Separera order, försändelser och spårningsdelsträckor

Använd inte spårningsnumret som primärnyckel för en order. En order kan innehålla flera paket och en paketrese kan involvera mer än en spårningsidentifierare. Skapa i stället ett internt försändelse-ID och koppla spårningsposter till det.

En praktisk modell har tre nivåer: kundordern, dess fysiska försändelser och de spårningsdelsträckor som hör till varje försändelse. Ett inhemskt paket kan behöva endast en spårningsdelsträcka. Ett gränsöverskridande paket kan behöva länkade poster när en annan transportör eller identifierare blir relevant.

Mer att läsa: Så förbättrar du leveransspårningen för gränsöverskridande order

Avgränsa en spårningspost efter både transportör och spårningsnummer och behåll dess relation till ditt försändelse-ID. Om ett nytt nummer från en leveranspartner dyker upp lägger du till det som en relaterad identifierare i stället för att skriva över det ursprungliga. På så sätt bevaras den historik som supportagenter behöver när de utreder en överlämning.

Behåll en rå händelse och en normaliserad händelse

Använd ett litet internt statusvokabulär som verksamheten kan agera på. Du kan till exempel definiera före transport, under transport, ute för leverans, tillgänglig för upphämtning, levererad, undantag och okänd. Detta är föreslagna interna kategorier, inte ett påstående om en viss leverantörs statusschema.

Lagra transportörens ursprungliga beskrivning tillsammans med den mappade statusen. En händelse vid ett utlämningsställe och ett adressproblem kan båda kräva åtgärder från kunden, men de bör inte skapa samma meddelande. På samma sätt bör skapandet av en fraktsedel inte automatiskt bli ett bevis på att transportören fysiskt har paketet.

Dokumentera mappningsbeslut i en versionshanterad konfiguration. När en ny händelsebeskrivning dyker upp placerar du den i en granskningskö om betydelsen är oklar. Ett uttryckligt okänt tillstånd är säkrare än att självsäkert tilldela fel leveransresultat.

Skilj mellan händelsetid och mottagningstid

Lagra när en händelse inträffade separat från när ditt system tog emot den. En äldre skanning kan komma efter en nyare, särskilt när uppdateringar är fördröjda eller historiska händelser levereras tillsammans.

För Australien och Nya Zeeland bör du undvika att använda en fast tidsförskjutning för varje försändelse. Bevara källans tidsstämplar och förskjutningar när de anges. Använd en lämplig namngiven tidszon för visning när du har tillförlitlig platskontext och ta hänsyn till skillnader i sommartid. Om källans tidszon saknas bör du behålla denna osäkerhet i stället för att hitta på en exakt UTC-konvertering.

Implementera ett tillförlitligt arbetsflöde för datainläsning

1. Skapa den interna försändelsen först. Registrera dess orderrelation, rutt, transportörsval och spårningsidentifierare innan den registreras hos spårningstjänsten.
2. Skicka spårningsregistreringen. Använd leverantörens dokumenterade format för begäran. Lagra svaret och skilj mellan lyckad registrering och den senare tillgängligheten av transportörshändelser.
3. Klassificera fel. Separera ogiltiga indata och autentiseringsproblem från tillfälliga tjänstefel. Försök endast igen när ett nytt försök rimligen kan hjälpa.
4. Ta emot eller hämta uppdateringar. Implementera den leveransmekanism som stöds av det valda API:t. Om du använder webhooks ska inkommande begäranden valideras med leverantörens dokumenterade metod och godkända händelser behandlas via en beständig kö.
5. Eliminera dubbletter innan ändringar tillämpas. Använd en leverantörshändelseidentifierare när den finns, eller en noggrant utformad sammansatt nyckel. Upprepad leverans får inte utlösa upprepade kundaviseringar.
6. Beräkna försändelsens status på nytt. Utvärdera händelsens betydelse och kronologi i stället för att ersätta den aktuella statusen med den uppdatering som kom senast.
7. Synkronisera ofullständiga poster. När API:t stöder hämtning använder du den för att undersöka missade uppdateringar eller inaktuella poster inom gällande användningsgränser.

Håll leverantörsspecifik autentisering, fältnamn och felhantering inne i en adapter. Ditt orderhanteringssystem bör använda din interna försändelsemodell i stället för att vara direkt beroende av varje detalj i ett leverantörssvar. Denna separering gör även senare API-ändringar enklare att testa.

Hantera resor över Tasmanhavet utan att skapa falsk säkerhet

Gränsöverskridande spårning behöver mer kontext än en följd av statusetiketter. Din applikation bör skilja mellan en exporthändelse, en tullrelaterad händelse, en överlämning mellan transportörer och en slutleveranshändelse när källdata stöder dessa skillnader.

Dra inte slutsatsen att tullklarering har skett från en generell skanning med statusen under transport. På samma sätt innebär avsaknaden av en nylig skanning inte att tullen håller paketet. Ett användbart kundmeddelande anger den senast bekräftade händelsen och dess tid och förklarar därefter nästa åtgärd som ditt team faktiskt kan stödja.

Håll ursprung och destination separerade från skanningsplatsen. En försändelse som transporteras från Australien till Nya Zeeland blir inte en inhemsk nyzeeländsk försändelse bara för att den har fått en ankomstskanning. Denna skillnad är viktig för rattrapportering och ansvar för undantag.

Om en leveranspartner blir involverad länkar du dess spårningspost endast när relationen stöds av försändelsedata, spårningstjänsten eller en operativt verifierad post. Slå inte samman paket bara för att identifierarna ser likadana ut.

Gör spårningshändelser till användbara kunduppdateringar

Din kundinriktade sida bör besvara fyra frågor: vilken är den senast bekräftade statusen, när inträffade den, var registrerades den om det är känt och behöver kunden agera?

Håll aviseringsregler separerade från händelseinläsningen. Alla skanningar förtjänar inte ett e-postmeddelande eller SMS. Definiera meningsfulla övergångar, till exempel den första bekräftade transporten, ett leveransförsök, ett krav på upphämtning eller en levererad-händelse, och undertryck upprepade aviseringar för samma övergång.

• Inaktuell spårning: Ange när den senaste uppdateringen inträffade utan att behandla tystnad som bevis på förlust.
• Leveransuppskattningar: Skilj mellan en uppskattning från transportören och ett löfte från säljaren. Hitta inte på ett datum när inget av dem finns.
• Undantag: Ange ett konkret nästa steg när det är känt, i stället för att visa en oförklarad feletikett.
• Tvister om leverans: Bevara källhändelsen och skicka ärendet till supporten. En levererad-status löser inte ensam alla kundtvister.

Skydda spårningssidorna såväl som API-uppgifterna. Undvik att exponera onödiga adress- eller kontaktuppgifter, förvara tjänsteinloggningar på servern och tillämpa åtkomstkontroller som är lämpliga för den information som visas.

Genomför ett ruttbaserat pilotprojekt före lansering

Testa inhemska australiska försändelser, inhemska nyzeeländska försändelser, försändelser från Australien till Nya Zeeland och från Nya Zeeland till Australien där dessa rutter är relevanta för din verksamhet. Ta med både vanliga leveranser och operativa specialfall: delade order, okända nummer, överlämningar, leveransförsök, upphämtningshändelser, returer och fördröjda skanningar.

17RETURNS Lösning för returer och byten

Minska supportkostnaderna och behåll mer intäkter med automatiserade returer och byten, med stöd av smarta verktyg för kundbevarande.

Prova gratis

Använd verkliga försändelseposter med lämpliga behörigheter för transportörsvalidering. Använd syntetiska händelser för att testa din egen applikations motståndskraft, men behandla inte syntetiska resultat som bevis på aktiv transportörtäckning.

• Identitetskontroll: Varje uppdatering når rätt försändelse och order.
• Kontroll av kronologi: Händelser i fel ordning vänder inte felaktigt på leveransförloppet.
• Återställningskontroll: Tillfälliga fel och dubbla uppdateringar leder inte till dataförlust eller upprepade aviseringar.
• Supportkontroll: Agenter kan granska den ursprungliga händelsen och förstå statusen som visas för kunden.
• Kommersiell kontroll: Förväntad användning ryms inom kontots verifierade faktureringsmodell och begränsningar.

Fastställ godkännandetrösklar innan du utvärderar piloten. Mät registreringsresultat, omappade händelser, behandlingsfördröjningar, dubbla aviseringar och olösta inaktuella försändelser. Skilj fördröjningar i transportörens data från fördröjningar i din egen applikation så att åtgärderna hamnar hos rätt ansvarig.

Implementationen är klar när ditt team kan förklara och återhämta sig från ofullständig spårning, inte bara visa lyckade leveranser. Ett API förenklar anslutningen; din försändelsemodell, dina händelseregler och dina arbetsrutiner gör anslutningen tillförlitlig.

Mer att läsa: Hur väljer man ett spårnings-API för e-handel?

Vanliga frågor

Ersätter ett spårnings-API integrationer för transportörers frakttjänster?

Inte nödvändigtvis. Spårning, skapande av fraktsedlar, bokning av upphämtning, prisberäkning och tulldokumentation är separata funktioner. Kontrollera det valda produktens omfattning och behåll andra integrationer där din orderhanteringsprocess behöver dem.

Du kanske också gillar: Bigcommerce-fraktintegrationer: alternativ för priser, etiketter och spårning

Kan jag registrera ett spårningsnummer före den första skanningen av transportören?

Kontrollera API:ts regler för registrering. Utforma din applikation så att den skiljer mellan en accepterad spårningsregistrering och bekräftad fysisk transport. En post utan händelser bör inte automatiskt visas som under transport.

Ger ett enda API realtidsuppdateringar för varje transportör?

Anta inte det. Aktualiteten från början till slut beror på när transportören publicerar data, när spårningstjänsten hämtar den och när din applikation behandlar den. Bekräfta uppdateringsbeteendet för de kombinationer av transportörer och tjänster som du använder.

Vad bör hända när spårningsnumret ändras?

Behåll den ursprungliga identifieraren och koppla den verifierade ersättnings- eller partneridentifieraren till samma interna försändelse. Bevara båda historikerna och förhindra att dubbla poster skapar motstridiga aviseringar.

Är 17TRACK relevant för denna integration?

Ja. Dess Tracking API är relevant för den integration med flera transportörer som beskrivs här. Utvärdera det med dina australiska och nyzeeländska försändelseprover och bekräfta stöd för transportörer, tekniskt beteende och kontovillkor via de officiella API-resurserna före lansering.

Källor

• 17TRACK Tracking API — officiell produktresurs för det API-alternativ som diskuteras i denna guide.
• 17TRACK API-dokumentation — officiell teknisk referens för kontroll av begärandeformat, integrationskrav och stödda funktioner.