Tracking API verzus Shipping API: Ktoré z nich váš e-commerce stack potrebuje (alebo obe)?

Použite shipping API, keď váš ecommerce stack potrebuje vytvárať zásielky a generovať prepravné štítky. Tracking API použite vtedy, keď potrebuje po odoslaní sledovať zásielky a premieňať aktualizácie od prepravcov na užitočné prevádzkové informácie alebo informácie určené zákazníkom. Obe funkcie potrebujete, ak váš softvér musí spravovať vytváranie zásielok aj viditeľnosť po nákupe, no nevyhnutne nepotrebujete dvoch poskytovateľov ani dve samostatné integrácie.

Rozhodnutie patrí osobe zodpovednej za vašu fulfillment architektúru: zvyčajne vedúcemu ecommerce prevádzky, ktorý spolupracuje s vývojovým tímom. Začnite tým, že zistíte, čo už zabezpečuje váš obchod, sklad alebo fulfillment partner. Pridanie ďalšieho API by malo odstrániť konkrétnu medzeru, nie duplikovať workflow, ktorý už funguje.

Aký je rozdiel medzi tracking API a shipping API?

Rozdiel spočíva predovšetkým v úlohe, ktorú každé API plní, nie v pevnej hranici medzi kategóriami produktov. Shipping platforma môže obsahovať endpointy na sledovanie, zatiaľ čo trackingová služba môže poskytovať nástroje na notifikácie a zákaznícke aktualizácie doručenia. Posudzujte zdokumentované endpointy a správanie udalostí, nie názov produktu.

Rozmer rozhodovania	Tracking API	Shipping API
Hlavná úloha	Načítať alebo prijímať stav zásielky a sledovacie udalosti.	Vytvárať zásielky a získavať štítky a súvisiace prepravné dokumenty.
Typické vstupy	Sledovacie číslo, identifikátor prepravcu a všetky ďalšie požadované údaje o zásielke.	Údaje o odosielateľovi a príjemcovi, informácie o balíku, výber služby a príslušné colné údaje.
Typické výstupy	Stav zásielky, história udalostí a ďalšie dostupné informácie o doručení.	Identifikátory zásielky, štítky a podporované dokumenty.
Hlavný workflow	Viditeľnosť doručenia, riešenie výnimiek a aktualizácie po nákupe.	Odoslanie zo skladu a príprava odchádzajúcej zásielky.
Čo nepredpokladať	Že prístup k sledovaniu zahŕňa vytvorenie štítku alebo rezerváciu u prepravcu.	Že vytvorenie štítku zahŕňa hĺbku sledovania a možnosti notifikácií, ktoré potrebujete.

Dokumentácia prepravcov ilustruje toto oddelenie. FedEx dokumentuje vytváranie zásielok vo svojej dokumentácii Ship API a funkcie sledovania vo svojej dokumentácii tracking API. Ide o príklady rôznych technických zodpovedností, nie o odporúčanie vybrať si konkrétneho prepravcu.

Vytvorenie zásielky nie je to isté ako sledovanie jej pohybu

Úspešná odpoveď na vytvorenie zásielky informuje váš softvér, že požiadavka na prepravu bola spracovaná. Nepotvrdzuje však, že prepravca balík fyzicky prevzal. Rovnako môže sledovacie číslo existovať ešte predtým, než sa v histórii sledovania objaví pohyb.

Váš systém správy objednávok by preto mal rozlišovať medzi vytvorením štítku, odovzdaním v sklade, prijatím prepravcom a doručením. Ak sa všetky tieto udalosti označia ako jediná udalosť „odoslané“, môže to viesť k predčasným správam zákazníkom a skryť balíky, ktoré v skutočnosti ešte neopustili sklad.

Vyberte funkciu, ktorá odstráni vaše aktuálne úzke hrdlo

Vyberte shipping API, keď chýba odoslanie

Shipping API je vhodným východiskom vtedy, keď vaša aplikácia musí premeniť údaje objednávky na zásielku. Príkladom je skladový tím, ktorý manuálne kopíruje adresy do portálov prepravcov, alebo vlastný systém správy objednávok, ktorý nedokáže generovať štítky.

Pred výberom integrácie definujte skutočný workflow odoslania. Potrebujete iba vytváranie zásielok, alebo aj získavanie sadzieb, zrušenie, požiadavky na vyzdvihnutie, colnú dokumentáciu či procesy na konci dňa? Tieto funkcie môžu byť samostatnými API, môžu závisieť od prepravcu alebo vyžadovať ďalšie oprávnenia účtu. Nepredpokladajte, že produkt označený ako „shipping API“ zahŕňa všetky prepravné operácie.

Nie je ideálne ako jediné riešenie: integrácia na vytváranie štítkov, po ktorej musí tím zákazníckej podpory kontrolovať jednotlivé webové stránky prepravcov. Môže vyriešiť odoslanie, no viditeľnosť doručenia zostane do veľkej miery nezmenená.

Vyberte tracking API, keď vytváranie zásielok už funguje

Tracking API je vhodnejšou voľbou vtedy, keď štítky už vytvára váš systém správy skladu, fulfillment partner, marketplace alebo existujúca shipping integrácia, no informácie o doručení sú rozptýlené.

V takejto situácii môže nahradenie workflow štítkov priniesť migračnú prácu bez vyriešenia hlavného problému. Namiesto toho prepojte sledovacie čísla generované upstream systémom s vrstvou viditeľnosti, ktorú môže využívať váš systém správy objednávok, nástroje podpory a komunikácia so zákazníkmi.

Pre túto kategóriu je 17TRACK Tracking API relevantnou možnosťou integrácie. Jeho oficiálna dokumentácia API opisuje registráciu sledovacích čísel a workflow so sledovacími údajmi vrátane push notifikácií. Posúďte tieto workflow vo vzťahu k požadovaným prepravcom, typom zásielok a architektúre aplikácie. Ide o hľadisko trackingovej vrstvy, nie o dôkaz, že služba nahrádza integráciu na generovanie štítkov.

Nie je ideálne ako jediné riešenie: tracking API v prípade, že váš softvér stále nemá spôsob, ako vytvárať zásielky, za ktorých odoslanie zodpovedá. Viditeľnosť sledovania nevyrieši chýbajúcu realizáciu prepravy.

Použite obe funkcie, keď vaša aplikácia spravuje odoslanie aj viditeľnosť doručenia

Obe funkcie sú vhodné vtedy, keď váš stack musí generovať štítky a následne udržiavať spoľahlivý prehľad o priebehu zásielky. Môžu pochádzať z jednej platformy, samostatných služieb alebo z kombinácie integrácií prepravcov a trackingovej vrstvy.

Uprednostnite jednu integráciu, ak jej funkcie prepravy a sledovania spĺňajú vaše zdokumentované požiadavky bez zbytočných kompromisov. O samostatných integráciách uvažujte vtedy, keď sa oplatí zachovať existujúci prepravný workflow alebo keď sa požiadavky na sledovanie výrazne líšia od toho, čo tento workflow poskytuje. Samostatný trackingový poskytovateľ nie je automaticky lepší; musí odôvodniť dodatočnú integráciu, fakturáciu a prevádzkovú zodpovednosť.

Ako obe API zapadajú do ecommerce stacku

Praktický návrh uchováva objednávku, zásielku a sledovaciu udalosť ako samostatné záznamy. Jedna objednávka môže vytvoriť viacero balíkov a každý balík môže mať vlastnú históriu sledovania. Stav objednávky zobrazený zákazníkovi by mal vychádzať z týchto záznamov zásielok, nie ich prepisovať.

1. Objednávka je pripravená na fulfillment. Obchod alebo systém správy objednávok odošle požadované údaje o fulfillmente zodpovednému skladu.
2. Prepravný workflow vytvorí zásielku. Aplikácia uloží vrátený identifikátor zásielky, sledovacie číslo, prepravcu, službu a referenciu na štítok.
3. Sklad dokončí odovzdanie. Potvrdenie skladu a prijatie prepravcom zostávajú rozlíšiteľnými udalosťami.
4. Spustí sa trackingový workflow. Aplikácia zaregistruje alebo odošle sledovacie číslo podľa požiadaviek vybranej integrácie.
5. Aktualizácie sledovania sa dostanú do aplikácie. Webhooky, polling alebo podporovaná kombinácia napĺňajú záznam zásielky.
6. Obchodné pravidlá určia ďalší postup. Systém aktualizuje stav zobrazený zákazníkovi, vytvorí prevádzkovú úlohu alebo odošle správu, keď sú splnené relevantné podmienky.

Obchodník využívajúci externý fulfillment sklad môže vo vlastnom softvéri potrebovať iba kroky štyri až šesť. Sklad už zabezpečuje vytváranie zásielok. Obchodník prevádzkujúci vlastný sklad môže potrebovať celý workflow.

Priraďte jedného vlastníka každej následnej akcii

Ak obe integrácie poskytujú aktualizácie sledovania, určte, ktorý systém riadi notifikácie zákazníkom a stav zásielky zobrazený vo vašom obchode. V opačnom prípade môžu zákazníci dostávať duplicitné správy alebo vidieť protichodné stavy doručenia.

Sekundárne údaje si môžete ponechať na účely vyšetrovania bez toho, aby každý zdroj mohol spúšťať e-mail. Pôvodnú udalosť prepravcu uchovajte spolu s mapovaním interného stavu, aby pracovníci podpory rozumeli, prečo systém zásielku klasifikoval určitým spôsobom.

Porovnávajte prevádzkovú vhodnosť, nie označenia funkcií

Overte prepravcov a služby, ktoré skutočne používate

Podpora prepravcu nie je jednoduchá otázka áno alebo nie. Služba môže podporovať sledovanie prepravcu bez podpory vytvárania štítkov pre daného prepravcu. Vytváranie štítkov môže tiež závisieť od krajiny pôvodu, nastavenia účtu prepravcu alebo oprávnenosti služby.

Vytvorte testovací zoznam podľa skutočných prepravných trás. Zahrňte domáce balíky, medzinárodné zásielky a všetky odovzdania medzi dopravnými partnermi. Pri každej potvrďte požadovanú operáciu: vytvorenie zásielky, sledovanie alebo oboje. Široké tvrdenie o pokrytí je menej užitočné než úspešné testy služieb, od ktorých vaša firma závisí.

Preskúmajte význam udalostí a úplnosť údajov

Pri sledovaní testujte, čo sa stane pred prvým skenom, počas výnimky pri doručení, po neúspešnom pokuse o doručenie a pri doručení. Skontrolujte, či časové pečiatky obsahujú informácie o časovom pásme a či zostávajú dostupné pôvodné opisy udalostí od prepravcu.

Normalizovaný stav neinterpretujte ako prísľub rovnakých údajov pri každom prepravcovi. Odhadované dátumy doručenia, podrobnosti o polohe a informácie o potvrdení doručenia môžu závisieť od konkrétneho prepravcu a zásielky. Rozhodnite, ako sa bude vaše rozhranie správať, keď tieto polia chýbajú.

Skontrolujte obnovu po zlyhaní na oboch stranách

Pri preprave si osobitnú pozornosť zaslúži timeout počas vytvárania zásielky: požiadavka mohla byť úspešná, aj keď vaša aplikácia nedostala odpoveď. Pred slepým opakovaním overte podporované mechanizmy poskytovateľa na prevenciu duplicít a zosúladenie údajov.

Pri sledovaní testujte duplicitné notifikácie, oneskorené udalosti, neúspešné doručenie webhooku a dočasné výpadky endpointov. V relevantnej dokumentácii potvrďte autentifikáciu, správanie pri opakovaní a možnosti obnovy. Spracovanie udalostí navrhnite tak, aby opätovné prehratie aktualizácie neposlalo rovnakú notifikáciu zákazníkovi znova.

Porovnajte celkové prevádzkové náklady bez predpokladania cenového modelu

Oddeľte poplatky za API od poštovného a poplatkov za účet prepravcu. Prepravné a trackingové služby môžu používať odlišné fakturačné jednotky a kombinovaná platforma môže funkcie baliť inak. Získajte cenovú ponuku alebo si preštudujte príslušný plán pre presný workflow, ktorý plánujete prevádzkovať.

Zistite, ako sa definuje spoplatnené používanie, či sa započítavajú neúspešné požiadavky, ako sa spracúvajú opakované odoslania na sledovanie a čo sa stane po prekročení limitu. Zahrňte údržbu zo strany vývojárov, náklady na podporu a náklady na udržiavanie konzistentnosti dvoch integrácií. Bez definovaného mixu zásielok a aktuálnych obchodných podmienok by bolo vyhlásenie, že jedna kategória je lacnejšia, zavádzajúce.

Preskúmajte bezpečnosť a uchovávanie údajov

Prepravné integrácie môžu spracúvať adresy príjemcov a colné údaje. Trackingové integrácie môžu tiež spracúvať identifikátory zásielok a súvisiace zákaznícke údaje. Overte, ktoré polia sú povinné, obmedzte prihlasovacie údaje na nevyhnutný prístup a tajomstvá uchovávajte mimo kódu na strane prehliadača.

Požiadavky na uchovávanie, mazanie a riadenie prístupu posúďte podľa potrieb svojej firmy. Pohodlná integrácia by nemala vyžadovať odosielanie zákazníckych informácií, ktoré workflow nepotrebuje.

Praktický plán overenia pred prijatím rozhodnutia

Vykonajte proof of concept s reprezentatívnymi zásielkami, nie iba s úspešným príkladom z rýchleho úvodného návodu. Dohodnite si akceptačné kritériá s prevádzkou, vývojom a zákazníckou podporou.

• Odoslanie: vygenerujte požadované formáty štítkov a potvrďte, že ich skladové zariadenia dokážu používať.
• Mapovanie objednávok: otestujte rozdelené zásielky, viacero balíkov a náhradné zásielky bez straty pôvodnej histórie.
• Sledovanie: skontrolujte skutočné sekvencie udalostí pre prepravcov a trasy, ktoré sú pre vašu firmu dôležité.
• Výnimky: overte, že riešiteľný problém s doručením sa dostane k správnemu tímu bez automatického označenia každého neobvyklého skenu za zlyhanie.
• Obnova: prerušte požiadavku alebo endpoint webhooku a predveďte, ako aplikácia zosúladí chýbajúce informácie.
• Komunikácia: potvrďte, že každú notifikáciu zákazníkovi odosiela iba určený systém.
• Obchodná vhodnosť: odhadnite poplatky pomocou očakávaného používania a potvrdených fakturačných definícií poskytovateľa.

Pravidlo rozhodovania: najprv si zaobstarajte chýbajúcu funkciu. Ak odoslanie už funguje, vyhodnoťte trackingovú integráciu bez prestavby fulfillmentu. Ak chýba vytváranie štítkov, najprv vyriešte realizáciu prepravy. Ak vaša aplikácia spravuje celý životný cyklus zásielky, overte obe funkcie a rozhodnite, či je pre váš tím jednoduchšie prevádzkovať kombinovanú alebo oddelenú architektúru.

Často kladené otázky

Zahŕňa shipping API vždy aj sledovanie?

Nie. Niektoré služby zahŕňajú obe funkcie, zatiaľ čo iné ich sprístupňujú prostredníctvom samostatných endpointov, produktov alebo plánov. Aj keď je sledovanie zahrnuté, pred jeho použitím ako riešenia sledovania po nákupe overte podrobnosť udalostí, spôsob doručovania aktualizácií, podporu prepravcov a podmienky používania.

Môžem sledovať balíky, ktorých štítky vytvoril fulfillment partner?

Potenciálne áno. Vaša aplikácia potrebuje identifikátory požadované trackingovou integráciou, zvyčajne sledovacie číslo a v prípade potreby identifikátor prepravcu alebo ďalšie overovacie informácie. Potvrďte podporu prepravcov partnera a uistite sa, že sledovacie čísla sa do vášho systému prenášajú spoľahlivo.

Spôsobí tracking API, že skeny prepravcu sa uskutočnia skôr?

Nemôže vytvárať fyzické skeny prepravcu. Môže vašej aplikácii pomôcť načítať, usporiadať a distribuovať informácie dostupné prostredníctvom jej zdrojov sledovania. Správanie aktualizácií posudzujte podľa skutočných zásielok a nepredpokladajte, že API zaručuje okamžitú viditeľnosť každého pohybu.

Potrebujem na používanie oboch funkcií dvoch poskytovateľov API?

Nie. Potrebujete obe funkcie, nie nevyhnutne dvoch dodávateľov. Použite jedného poskytovateľa, ak spĺňa vaše požiadavky na prepravu a sledovanie. Oddeľte ich vtedy, keď tým zachováte fungujúci workflow alebo splníte konkrétnu požiadavku, ktorú kombinovaná možnosť nespĺňa.

Môže tracking API nahradiť systém správy objednávok?

Nie. Sledovacie údaje sú vstupom do správy objednávok, nie náhradou za prideľovanie zásob, rozhodnutia o fulfillmente, spracovanie platieb alebo záznamy objednávok. Vaša aplikácia stále musí priradiť každú zásielku k správnej objednávke a rozhodnúť, ako udalosti zásielky ovplyvnia obchodné workflow.

Zdroje

• Dokumentácia FedEx Ship API — referencia pre vytváranie zásielok, štítky a požiadavky prepravného workflow.
• Dokumentácia FedEx tracking API — referencia pre požiadavky na sledovanie a informácie o stave zásielky.
• 17TRACK Tracking API — oficiálna produktová referencia pre kategóriu trackingových integrácií.
• Dokumentácia 17TRACK API — referencia pre registráciu sledovania, sledovacie údaje a integráciu push notifikácií.