Tracking API kundrejt Shipping API: Për cilin ka nevojë stack-u juaj i tregtisë elektronike (apo për të dyja)?

Përdorni një shipping API kur infrastruktura juaj e ecommerce duhet të krijojë dërgesa dhe të gjenerojë etiketa transporti. Përdorni një tracking API kur duhet të ndjekë dërgesat pas nisjes dhe t'i kthejë përditësimet e transportuesit në informacione të dobishme për operacionet ose për klientët. Ju nevojiten të dyja aftësitë nëse softueri juaj duhet të menaxhojë krijimin e dërgesave dhe dukshmërinë pas blerjes, por jo domosdoshmërisht dy ofrues ose dy integrime të veçanta.

Vendimi i përket personit që është përgjegjës për arkitekturën e përmbushjes së porosive: zakonisht një drejtues i operacioneve të ecommerce që punon me një ekip inxhinierik. Filloni duke identifikuar se çfarë menaxhon tashmë dyqani, magazina ose partneri juaj i përmbushjes së porosive. Shtimi i një API-je tjetër duhet të mbyllë një boshllëk specifik, jo të përsërisë një rrjedhë pune që tashmë funksionon.

Cili është ndryshimi midis një tracking API dhe një shipping API?

Dallimi lidhet kryesisht me detyrën që kryen secila API, jo me një kufi të ngurtë midis kategorive të produkteve. Një platformë transporti mund të përfshijë endpoint-e gjurmimi, ndërsa një shërbim gjurmimi mund të ofrojë mjete për njoftime dhe përditësime të dorëzimit të dukshme për klientët. Vlerësoni endpoint-et e dokumentuara dhe sjelljen e eventeve, në vend që të mbështeteni te emri i produktit.

Dimensioni i vendimit	Tracking API	Shipping API
Detyra kryesore	Marrja ose pranimi i statusit të dërgesës dhe eventeve të gjurmimit.	Krijimi i dërgesave dhe marrja e etiketave dhe dokumenteve përkatëse të transportit.
Input-et tipike	Numri i gjurmimit, identifikuesi i transportuesit dhe çdo detaj shtesë i kërkuar për dërgesën.	Të dhënat e dërguesit dhe marrësit, informacioni i paketës, zgjedhja e shërbimit dhe të dhënat doganore të zbatueshme.
Output-et tipike	Statusi i dërgesës, historia e eventeve dhe informacione të tjera të disponueshme për dorëzimin.	Identifikuesit e dërgesës, etiketat dhe dokumentet e mbështetura.
Rrjedha kryesore e punës	Dukshmëria e dorëzimit, trajtimi i përjashtimeve dhe përditësimet pas blerjes.	Nisja nga magazina dhe përgatitja e dërgesës për dalje.
Çfarë nuk duhet supozuar	Që qasja në gjurmim përfshin krijimin e etiketave ose rezervimin te transportuesi.	Që krijimi i etiketave përfshin thellësinë e gjurmimit dhe kontrollet e njoftimeve që ju nevojiten.

Dokumentacioni i transportuesve e ilustron këtë ndarje. FedEx dokumenton krijimin e dërgesave në dokumentacionin e Ship API dhe aftësitë e gjurmimit në dokumentacionin e tracking API. Këto janë shembuj të përgjegjësive të ndryshme teknike, jo rekomandim për të zgjedhur një transportues të caktuar.

Krijimi i një dërgese nuk është i njëjtë me vëzhgimin e lëvizjes së saj

Një përgjigje e suksesshme për krijimin e dërgesës i tregon softuerit tuaj se një kërkesë transporti është përpunuar. Ajo nuk vërteton se transportuesi e ka marrë fizikisht pakon. Po kështu, një numër gjurmimi mund të ekzistojë përpara se të shfaqet lëvizja në historinë e gjurmimit.

Prandaj, sistemi juaj i menaxhimit të porosive duhet të bëjë dallimin midis krijimit të etiketës, dorëzimit nga magazina, pranimit nga transportuesi dhe dorëzimit. Trajtimi i të gjitha këtyre si një event i vetëm “shipped” mund të prodhojë mesazhe të parakohshme për klientët dhe të fshehë pakot që në të vërtetë nuk janë larguar nga magazina.

Zgjidhni aftësinë që zgjidh pengesën tuaj aktuale

Zgjidhni një shipping API kur pjesa që mungon është nisja

Një shipping API është pika e përshtatshme e nisjes kur aplikacioni juaj duhet t'i shndërrojë të dhënat e porosisë në një dërgesë. Shembujt përfshijnë një ekip magazine që kopjon manualisht adresat në portalet e transportuesve ose një sistem të personalizuar menaxhimi porosish që nuk mund të gjenerojë etiketa.

Përpara se të zgjidhni një integrim, përcaktoni rrjedhën reale të nisjes. A ju nevojitet vetëm krijimi i dërgesës, apo edhe marrja e tarifave, anulimi, kërkesat për marrje, dokumentacioni doganor ose proceset e fundit të ditës? Këto funksione mund të jenë API të veçanta, të varen nga transportuesi ose të kërkojnë leje shtesë të llogarisë. Mos supozoni se një produkt i quajtur “shipping API” përfshin çdo operacion transporti.

Jo ideale si zgjidhja e vetme: një integrim për krijimin e etiketave që e lë ekipin tuaj të shërbimit ndaj klientit të kontrollojë faqet individuale të transportuesve. Ai mund ta zgjidhë nisjen, ndërsa dukshmëria e dorëzimit mbetet kryesisht e pandryshuar.

Zgjidhni një tracking API kur krijimi i dërgesave tashmë funksionon

Një tracking API është zgjedhja më e drejtpërdrejtë kur etiketat krijohen tashmë nga sistemi juaj i menaxhimit të magazinës, partneri i përmbushjes së porosive, marketplace-i ose integrimi ekzistues i transportit, por informacioni i dorëzimit është i fragmentuar.

Në këtë situatë, zëvendësimi i rrjedhës së etiketave mund të shtojë punë migrimi pa zgjidhur problemin qendror. Në vend të kësaj, lidhni numrat e gjurmimit të gjeneruar më lart në proces me një shtresë dukshmërie që mund ta përdorin sistemi juaj i menaxhimit të porosive, mjetet e mbështetjes dhe komunikimet me klientët.

Për këtë kategori, 17TRACK Tracking API është një mundësi e përshtatshme integrimi. Dokumentacioni zyrtar i API-së përshkruan regjistrimin e numrave të gjurmimit dhe rrjedhat e të dhënave të gjurmimit, përfshirë njoftimet push. Vlerësoni këto rrjedha kundrejt transportuesve, llojeve të dërgesave dhe arkitekturës së aplikacionit që ju nevojiten. Ky është një vlerësim i shtresës së gjurmimit, jo provë se shërbimi zëvendëson një integrim për gjenerimin e etiketave.

Jo ideale si zgjidhja e vetme: një tracking API kur softueri juaj ende nuk ka mënyrë të krijojë dërgesat për të cilat është përgjegjës në nisje. Dukshmëria e gjurmimit nuk zgjidh mungesën e ekzekutimit të transportit.

Përdorini të dyja kur aplikacioni juaj kontrollon nisjen dhe dukshmërinë e dorëzimit

Të dyja aftësitë janë të përshtatshme kur infrastruktura juaj duhet të gjenerojë etiketa dhe më pas të mbajë një pamje të besueshme të përparimit të dërgesës. Ato mund të vijnë nga një platformë e vetme, shërbime të veçanta ose një kombinim integrimesh me transportues dhe një shtresë gjurmimi.

Preferoni një integrim të vetëm kur funksionet e tij të transportit dhe gjurmimit përmbushin kërkesat tuaja të dokumentuara pa ju detyruar të bëni kompromise të panevojshme. Merrni në konsideratë integrime të veçanta kur një rrjedhë ekzistuese transporti ia vlen të ruhet ose kur kërkesat e gjurmimit ndryshojnë dukshëm nga ato që ofron kjo rrjedhë. Një ofrues i veçantë gjurmimi nuk është automatikisht më i mirë; ai duhet të justifikojë integrimin, faturimin dhe përgjegjësinë operative shtesë.

Si përshtaten të dyja API-të në një infrastrukturë ecommerce

Një dizajn praktik i mban porosinë, dërgesën dhe eventin e gjurmimit si regjistrime të veçanta. Një porosi mund të prodhojë disa pako dhe secila pako mund të ketë historinë e vet të gjurmimit. Statusi i porosisë i dukshëm për klientin duhet të nxirret nga këto regjistrime dërgesash, në vend që t'i mbishkruajë ato.

1. Porosia bëhet gati për përmbushje. Dyqani ose sistemi i menaxhimit të porosive dërgon të dhënat e kërkuara të përmbushjes në magazinën përgjegjëse.
2. Rrjedha e transportit krijon dërgesën. Aplikacioni ruan identifikuesin e kthyer të dërgesës, numrin e gjurmimit, transportuesin, shërbimin dhe referencën e etiketës.
3. Magazina përfundon dorëzimin. Konfirmimi i magazinës dhe pranimi nga transportuesi mbeten evente të dallueshme.
4. Fillon rrjedha e gjurmimit. Aplikacioni juaj regjistron ose dërgon numrin e gjurmimit sipas kërkesave të integrimit të zgjedhur.
5. Përditësimet e gjurmimit arrijnë në aplikacionin tuaj. Webhook-et, polling-u ose një kombinim i mbështetur furnizon regjistrimin e dërgesës.
6. Rregullat e biznesit vendosin çfarë ndodh më pas. Sistemi juaj përditëson statusin e dukshëm për klientin, krijon një detyrë operative ose dërgon një mesazh kur plotësohen kushtet përkatëse.

Për shembull, një tregtar që përdor një magazinë të palës së tretë për përmbushjen e porosive mund të ketë nevojë vetëm për hapat katër deri në gjashtë në softuerin e vet. Magazina tashmë kontrollon krijimin e dërgesës. Një tregtar që operon magazinën e vet mund të ketë nevojë për rrjedhën e plotë.

Caktoni një përgjegjës për çdo veprim pasues

Nëse të dyja integrimet ofrojnë përditësime gjurmimi, përcaktoni se cili sistem kontrollon njoftimet për klientët dhe statusin e dërgesës që shfaqet në dyqanin tuaj. Përndryshe, klientët mund të marrin mesazhe të dyfishta ose të shohin statuse kontradiktore të dorëzimit.

Mund të ruani të dhëna dytësore për hetim pa lejuar që çdo burim të aktivizojë një email. Ruani eventin origjinal të transportuesit së bashku me hartëzimin e statusit tuaj të brendshëm, në mënyrë që stafi i mbështetjes të kuptojë pse sistemi e klasifikoi një dërgesë në një mënyrë të caktuar.

Krahasoni përshtatjen operative, jo etiketat e veçorive

Verifikoni transportuesit dhe shërbimet që përdorni realisht

Mbështetja e transportuesit nuk është një pyetje e vetme me përgjigje po ose jo. Një shërbim mund të mbështesë gjurmimin për një transportues pa mbështetur krijimin e etiketave për të njëjtin transportues. Krijimi i etiketave mund të varet gjithashtu nga vendi i origjinës, konfigurimi i llogarisë së transportuesit ose përshtatshmëria e shërbimit.

Ndërtoni një listë testimi nga linjat tuaja reale të transportit. Përfshini pakot vendase, dërgesat ndërkombëtare dhe çdo dorëzim midis partnerëve të transportit. Konfirmoni operacionin e kërkuar për secilën: krijimin e dërgesës, gjurmimin e saj ose të dyja. Një deklaratë e gjerë mbulimi është më pak e dobishme sesa testet e suksesshme të shërbimeve nga të cilat varet biznesi juaj.

Shqyrtoni kuptimin e eventeve dhe plotësinë e të dhënave

Për gjurmimin, testoni çfarë ndodh përpara skanimit të parë, gjatë një përjashtimi të dorëzimit, pas një tentative të dështuar dorëzimi dhe në momentin e dorëzimit. Kontrolloni nëse vulat kohore përfshijnë informacionin e zonës kohore dhe nëse përshkrimet origjinale të transportuesit mbeten të disponueshme.

Mos e interpretoni një status të normalizuar si premtim për të dhëna identike nga çdo transportues. Datat e parashikuara të dorëzimit, detajet e vendndodhjes dhe informacioni i provës së dorëzimit mund të varen nga transportuesi dhe dërgesa bazë. Vendosni si do të sillet ndërfaqja juaj kur këto fusha mungojnë.

Kontrolloni rikuperimin nga dështimet në të dyja anët

Për transportin, një timeout gjatë krijimit të dërgesës kërkon vëmendje të veçantë: kërkesa mund të ketë përfunduar me sukses edhe nëse aplikacioni juaj nuk e mori përgjigjen. Verifikoni mekanizmat e mbështetur nga ofruesi për parandalimin e dublikatave dhe rakordimin përpara se të riprovoni verbërisht.

Për gjurmimin, testoni njoftimet e dyfishta, eventet e vonuara, dorëzimin e pasuksesshëm të webhook-eve dhe ndërprerjet e përkohshme të endpoint-eve. Konfirmoni autentikimin, sjelljen e riprovimit dhe opsionet e rikuperimit në dokumentacionin përkatës. Projektoni përpunimin e eventeve në mënyrë që riprodhimi i një përditësimi të mos dërgojë përsëri të njëjtin njoftim për klientin.

Krahasoni koston totale operative pa supozuar një model çmimi

Ndani tarifat e API-së nga tarifat postare dhe tarifat e llogarisë së transportuesit. Shërbimet e transportit dhe gjurmimit mund të përdorin njësi të ndryshme faturimi, ndërsa një platformë e kombinuar mund t'i paketojë aftësitë ndryshe. Merrni një ofertë ose shqyrtoni planin e zbatueshëm për rrjedhën e saktë të punës që synoni të ekzekutoni.

Pyetni si përcaktohet përdorimi i faturueshëm, nëse llogariten kërkesat e pasuksesshme, si trajtohen dërgimet e përsëritura të gjurmimit dhe çfarë ndodh kur përdorimi tejkalon kufirin e lejuar. Përfshini mirëmbajtjen inxhinierike, përpjekjet e mbështetjes dhe koston e mbajtjes konsistente të dy integrimeve. Pa një përzierje të përcaktuar dërgesash dhe kushte aktuale tregtare, deklarimi se një kategori është më e lirë do të ishte çorientues.

Shqyrtoni sigurinë dhe ruajtjen e të dhënave

Integrimet e transportit mund të përpunojnë adresat e marrësve dhe informacionin doganor. Integrimet e gjurmimit mund të përpunojnë gjithashtu identifikuesit e dërgesave dhe të dhënat përkatëse të klientëve. Konfirmoni se cilat fusha kërkohen, kufizoni kredencialet në qasjen e nevojshme dhe mbajini sekretet larg kodit në anën e shfletuesit.

Shqyrtoni ruajtjen, fshirjen dhe kontrollet e qasjes kundrejt kërkesave të biznesit tuaj. Një integrim i përshtatshëm nuk duhet të kërkojë dërgimin e informacionit të klientit që rrjedha e punës nuk e ka të nevojshëm.

Një plan praktik validimi përpara angazhimit

Kryeni një provë koncepti duke përdorur dërgesa përfaqësuese dhe jo vetëm një shembull të suksesshëm nga një udhëzues i shpejtë. Dakordësoni kriteret e pranimit me operacionet, inxhinierinë dhe mbështetjen e klientit.

• Nisja: gjeneroni formatet e kërkuara të etiketave dhe konfirmoni se pajisjet e magazinës mund t'i përdorin.
• Hartëzimi i porosive: testoni dërgesat e ndara, paketat e shumta dhe dërgesat zëvendësuese pa humbur historinë origjinale.
• Gjurmimi: kontrolloni sekuencat reale të eventeve për transportuesit dhe rrugët që kanë rëndësi për biznesin tuaj.
• Përjashtimet: verifikoni që një problem i veprueshëm i dorëzimit të arrijë te ekipi i duhur pa e trajtuar automatikisht çdo skanim të pazakontë si dështim.
• Rikuperimi: ndërprisni një kërkesë ose endpoint webhook-u dhe demonstroni se si aplikacioni rakordon informacionin që mungon.
• Komunikimet: konfirmoni që vetëm sistemi i caktuar dërgon çdo njoftim për klientin.
• Përshtatja tregtare: vlerësoni tarifat duke përdorur përdorimin e pritshëm dhe përkufizimet e konfirmuara të faturimit nga ofruesi.

Rregulli i vendimit: blini fillimisht aftësinë që mungon. Nëse nisja tashmë funksionon, vlerësoni një integrim gjurmimi pa rindërtuar përmbushjen e porosive. Nëse mungon krijimi i etiketave, zgjidhni fillimisht ekzekutimin e transportit. Nëse aplikacioni juaj kontrollon të gjithë ciklin e jetës së dërgesës, validoni të dyja aftësitë dhe zgjidhni nëse një arkitekturë e kombinuar apo e ndarë është më e lehtë për t'u operuar nga ekipi juaj.

FAQ

A përfshin gjithmonë një shipping API gjurmimin?

Jo. Disa shërbime përfshijnë të dyja aftësitë, ndërsa të tjerat i ofrojnë përmes endpoint-eve, produkteve ose planeve të veçanta. Edhe kur gjurmimi përfshihet, verifikoni detajet e eventeve, mënyrën e dorëzimit të përditësimeve, mbështetjen e transportuesve dhe kushtet e përdorimit përpara se ta trajtoni si zgjidhjen tuaj të gjurmimit pas blerjes.

A mund të gjurmoj pako, etiketat e të cilave janë krijuar nga një partner përmbushjeje?

Potencialisht, po. Aplikacioni juaj ka nevojë për identifikuesit e kërkuar nga integrimi i gjurmimit, zakonisht duke përfshirë numrin e gjurmimit dhe, kur kërkohet, një identifikues të transportuesit ose informacion shtesë verifikimi. Konfirmoni mbështetjen për transportuesit e partnerit dhe sigurohuni që numrat e gjurmimit të kalojnë në mënyrë të besueshme në sistemin tuaj.

A do ta bëjë një tracking API që skanimet e transportuesit të ndodhin më shpejt?

Nuk mund të krijojë skanime fizike të transportuesit. Ajo mund ta ndihmojë aplikacionin tuaj të marrë, organizojë dhe shpërndajë informacionin e vënë në dispozicion nga burimet e tij të gjurmimit. Vlerësoni sjelljen e përditësimeve me dërgesa reale, në vend që të supozoni se një API garanton dukshmëri të menjëhershme për çdo lëvizje.

A më duhen dy ofrues API-sh për të përdorur të dyja aftësitë?

Jo. Ju nevojiten të dyja funksionet, jo domosdoshmërisht dy shitës. Përdorni një ofrues kur ai përmbush kërkesat tuaja të transportit dhe gjurmimit. Ndajini kur kjo ruan një rrjedhë pune funksionale ose përmbush një kërkesë specifike që opsioni i kombinuar nuk e plotëson.

A mund ta zëvendësojë një tracking API një sistem të menaxhimit të porosive?

Jo. Të dhënat e gjurmimit janë input për menaxhimin e porosive, jo zëvendësim për alokimin e inventarit, vendimet e përmbushjes, trajtimin e pagesave ose regjistrimet e porosive. Aplikacioni juaj ende duhet ta lidhë çdo dërgesë me porosinë e saktë dhe të vendosë se si eventet e dërgesës ndikojnë te rrjedhat e punës së biznesit.

Burimet

• Dokumentacioni i FedEx Ship API — referencë për krijimin e dërgesave, etiketat dhe kërkesat e rrjedhës së transportit.
• Dokumentacioni i FedEx tracking API — referencë për kërkesat e gjurmimit dhe informacionin e statusit të dërgesave.
• 17TRACK Tracking API — referencë zyrtare e produktit për kategorinë e integrimeve të gjurmimit.
• Dokumentacioni i 17TRACK API — referencë për regjistrimin e gjurmimit, të dhënat e gjurmimit dhe integrimin e njoftimeve push.