API за следење наспроти API за испорака: Кое му е потребно на вашиот стек за е-трговија (или и двете)?

Користете shipping API кога вашиот ecommerce стек треба да креира пратки и да генерира транспортни етикети. Користете tracking API кога треба да ги следи пратките по испраќањето и ажурирањата од превозниците да ги претвори во корисни оперативни информации или информации за клиентите. Ви се потребни и двете можности ако вашиот софтвер мора да управува со креирањето пратки и видливоста по купувањето, но не мора да имате два добавувачи или две одделни интеграции.

Одлуката му припаѓа на оној што ја управува вашата архитектура за исполнување на нарачките: обично раководител на ecommerce операции кој работи со инженерски тим. Започнете со утврдување на тоа што веќе го управуваат вашата продавница, магацин или партнер за исполнување на нарачки. Додавањето друг API треба да пополни конкретен недостаток, а не да дуплира работен тек што веќе функционира.

Која е разликата помеѓу tracking API и shipping API?

Разликата првенствено се однесува на задачата што ја извршува секој API, а не на строга граница помеѓу категориите производи. Платформа за испорака може да вклучува endpoints за следење, додека услуга за следење може да обезбедува алатки за известувања и ажурирања за испораката наменети за клиентите. Оценувајте ги документираните endpoints и однесувањето на настаните, наместо да се потпирате на името на производот.

Димензија на одлуката	Tracking API	Shipping API
Главна задача	Преземање или примање на статусот на пратката и настаните за следење.	Креирање пратки и добивање етикети и поврзани документи за испорака.
Типични влезни податоци	Број за следење, идентификатор на превозникот и сите дополнителни потребни детали за пратката.	Податоци за испраќачот и примачот, информации за пакетот, избор на услуга и применливи царински податоци.
Типични излезни податоци	Статус на пратката, историја на настани и други достапни информации за испораката.	Идентификатори на пратката, етикети и поддржани документи.
Главен работен тек	Видливост на испораката, справување со исклучоци и ажурирања по купувањето.	Испраќање од магацин и подготовка на излезната пратка.
Што да не претпоставувате	Дека пристапот до следење вклучува креирање етикети или резервирање кај превозникот.	Дека креирањето етикети ја вклучува длабочината на следење и контролите за известувања што ви се потребни.

Документацијата на превозниците ја илустрира оваа поделба. FedEx го документира креирањето пратки во својата документација за Ship API, а можностите за следење во својата документација за tracking API. Ова се примери за различни технички одговорности, а не препорака за избор на конкретен превозник.

Креирањето пратка не е исто што и следењето на нејзиното движење

Успешниот одговор при креирање пратка му кажува на вашиот софтвер дека барањето за испорака е обработено. Тоа не потврдува дека превозникот физички го примил пакетот. Исто така, бројот за следење може да постои пред да се појави движење во историјата на следење.

Затоа вашиот систем за управување со нарачки треба да прави разлика помеѓу креирање етикета, предавање од магацин, прием од превозникот и испорака. Ако сите овие настани ги третирате како еден единствен настан „испратено“, може да испратите прерани пораки до клиентите и да ги сокриете пакетите што всушност не го напуштиле магацинот.

Изберете ја можноста што го решава вашето тековно тесно грло

Изберете shipping API кога испраќањето е делот што недостасува

Shipping API е соодветната почетна точка кога вашата апликација треба да ги претвори податоците за нарачката во пратка. Примери се тим во магацин кој рачно ги внесува адресите во порталите на превозниците или сопствен систем за управување со нарачки кој не може да генерира етикети.

Пред да изберете интеграција, дефинирајте го реалниот работен тек за испраќање. Дали ви е потребно само креирање пратка или и преземање тарифи, откажување, барања за преземање, царинска документација или процеси на крајот од денот? Овие функции може да бидат одделни API-ја, да зависат од превозникот или да бараат дополнителни дозволи на сметката. Не претпоставувајте дека производ означен како „shipping API“ ја вклучува секоја операција за испорака.

Не е идеално како единствено решение: интеграција за креирање етикети поради која вашиот тим за корисничка поддршка мора да ги проверува веб-страниците на одделните превозници. Таа може да го реши испраќањето, но видливоста на испораката да остане главно непроменета.

Изберете tracking API кога креирањето пратки веќе функционира

Tracking API е подиректен избор кога етикетите веќе ги креираат вашиот систем за управување со магацин, партнерот за исполнување на нарачки, marketplace или постојната интеграција за испорака, но информациите за испораката се фрагментирани.

Во таква ситуација, заменувањето на работниот тек за етикети може да додаде работа околу миграцијата без да го реши централниот проблем. Наместо тоа, поврзете ги броевите за следење генерирани нагоре во процесот со слој за видливост што можат да го користат вашиот систем за управување со нарачки, алатките за поддршка и комуникациите со клиентите.

За оваа категорија, 17TRACK Tracking API е релевантна опција за интеграција. Неговата официјална API документација ги опишува работните текови за регистрирање броеви за следење и податоци за следење, вклучувајќи push известувања. Оценете ги тие работни текови според превозниците, видовите пратки и архитектурата на апликацијата што ви се потребни. Ова е прашање на слојот за следење, а не доказ дека услугата ја заменува интеграцијата за генерирање етикети.

Не е идеално како единствено решение: tracking API кога вашиот софтвер сè уште нема начин да ги креира пратките за кои е одговорен при испраќањето. Видливоста на следењето не го решава недостатокот на извршување на испораката.

Користете ги двете можности кога вашата апликација управува со испраќањето и видливоста на испораката

Двете можности се соодветни кога вашиот стек мора да генерира етикети, а потоа да одржува сигурен преглед на напредокот на пратката. Тие може да доаѓаат од една платформа, од одделни услуги или од комбинација на интеграции со превозници и слој за следење.

Претпочитајте една интеграција кога нејзините функции за испорака и следење ги исполнуваат вашите документирани барања без непотребни компромиси. Размислете за одделни интеграции кога постојниот работен тек за испорака вреди да се зачува или кога барањата за следење суштински се разликуваат од она што го обезбедува тој работен тек. Одделен добавувач за следење не е автоматски подобар; тој мора да ја оправда дополнителната интеграција, наплата и оперативна одговорност.

Како двата API-ја се вклопуваат во ecommerce стек

Практичниот дизајн ги чува нарачката, пратката и настанот за следење како одделни записи. Една нарачка може да произведе неколку пакети, а секој пакет може да има сопствена историја на следење. Статусот на нарачката прикажан на клиентот треба да се изведува од тие записи за пратките, наместо да ги заменува.

1. Нарачката станува подготвена за исполнување. Продавницата или системот за управување со нарачки ги испраќа потребните податоци за исполнување до одговорниот магацин.
2. Работниот тек за испорака ја креира пратката. Апликацијата ги зачувува вратениот идентификатор на пратката, бројот за следење, превозникот, услугата и референцата на етикетата.
3. Магацинот го завршува предавањето. Потврдата од магацинот и приемот од превозникот остануваат различни настани.
4. Започнува работниот тек за следење. Вашата апликација го регистрира или испраќа бројот за следење според барањата на избраната интеграција.
5. Ажурирањата за следење стигнуваат до вашата апликација. Webhooks, polling или поддржана комбинација ги ажурираат записите за пратката.
6. Деловните правила одлучуваат што следува. Вашиот систем го ажурира статусот видлив за клиентот, создава оперативна задача или испраќа порака кога ќе се исполнат релевантните услови.

На пример, трговец кој користи магацин на трета страна за исполнување на нарачките можеби во сопствениот софтвер ќе ги има потребни само чекорите четири до шест. Магацинот веќе управува со креирањето пратки. Трговец кој управува со сопствен магацин можеби ќе го има потребен целиот тек.

Назначете еден одговорен систем за секое дејство по испораката

Ако двете интеграции обезбедуваат ажурирања за следење, определете кој систем ги контролира известувањата до клиентите и статусот на пратката прикажан во вашата продавница. Во спротивно, клиентите може да добијат дуплирани пораки или да видат спротивставени статуси на испорака.

Можете да ги задржите секундарните податоци за истрага без да дозволите секој извор да активира е-пошта. Зачувајте го оригиналниот настан од превозникот заедно со вашето внатрешно мапирање на статуси за вработените во поддршката да можат да разберат зошто системот ја класифицирал пратката на одреден начин.

Оценувајте ја оперативната соодветност, а не ознаките на функциите

Проверете ги превозниците и услугите што навистина ги користите

Поддршката за превозници не е едноставно прашање со одговор да или не. Услугата може да поддржува следење за одреден превозник без да поддржува креирање етикети за истиот превозник. Креирањето етикети може да зависи и од земјата на потекло, поставувањето на сметката кај превозникот или подобноста за услугата.

Направете тест-листа врз основа на вашите реални транспортни рути. Вклучете домашни пакети, меѓународни пратки и секое предавање помеѓу транспортни партнери. Потврдете ја потребната операција за секоја од нив: креирање пратка, следење или и двете. Широкото тврдење за покриеност е помалку корисно од успешните тестови на услугите од кои зависи вашиот бизнис.

Проверете го значењето на настаните и целосноста на податоците

За следењето, тестирајте што се случува пред првото скенирање, за време на исклучок при испораката, по неуспешен обид за испорака и при испораката. Проверете дали временските ознаки содржат информации за временската зона и дали оригиналните описи на превозникот остануваат достапни.

Не толкувајте го нормализираниот статус како ветување за идентични податоци кај секој превозник. Проценетите датуми на испорака, деталите за локацијата и информациите за доказ за испорака може да зависат од превозникот и пратката. Одлучете како ќе се однесува вашиот интерфејс кога тие полиња недостасуваат.

Проверете го опоравувањето од грешки на двете страни

За испораката, timeout при креирање пратка заслужува посебно внимание: барањето можеби успеало иако вашата апликација не го примила одговорот. Пред слепо повторување, проверете ги поддржаните механизми на добавувачот за спречување дупликати и усогласување.

За следењето, тестирајте дуплирани известувања, задоцнети настани, неуспешна испорака на webhook и привремени прекини на endpoint-ите. Потврдете ги автентикацијата, однесувањето при повторување и можностите за опоравување во релевантната документација. Обработката на настани дизајнирајте ја така што повторното пуштање на ажурирање нема повторно да го испрати истото известување до клиентот.

Споредете ги вкупните оперативни трошоци без да претпоставувате модел на наплата

Одделете ги трошоците за API од поштарината и трошоците за сметката кај превозникот. Услугите за испорака и следење може да користат различни единици за наплата, а комбинираната платформа може различно да ги пакетира можностите. Побарајте понуда или разгледајте го применливиот план за точниот работен тек што планирате да го извршувате.

Прашајте како се дефинира наплатливото користење, дали се бројат неуспешните барања, како се обработуваат повторените поднесувања за следење и што се случува кога користењето ќе го надмине дозволениот лимит. Вклучете го инженерското одржување, напорот за поддршка и трошокот за одржување на конзистентноста помеѓу две интеграции. Без дефиниран состав на пратки и тековни комерцијални услови, тврдењето дека една категорија е поевтина би било погрешно.

Прегледајте ја безбедноста и задржувањето на податоците

Интеграциите за испорака може да обработуваат адреси на примачи и царински информации. Интеграциите за следење може да обработуваат и идентификатори на пратки и поврзани податоци за клиентите. Потврдете кои полиња се задолжителни, ограничете ги акредитивите на потребниот пристап и чувајте ги тајните податоци надвор од кодот на страната на прелистувачот.

Прегледајте ги задржувањето, бришењето и контролите на пристап во однос на вашите деловни барања. Практичната интеграција не треба да бара испраќање информации за клиентите што не му се потребни на работниот тек.

Практичен план за проверка пред обврзување

Спроведете proof of concept со репрезентативни пратки, а не само со успешен пример од водич за брз почеток. Договорете критериуми за прифаќање со операциите, инженерството и корисничката поддршка.

• Испраќање: генерирајте ги потребните формати на етикети и потврдете дека опремата во магацинот може да ги користи.
• Мапирање на нарачки: тестирајте поделени пратки, повеќе пакети и заменски пратки без губење на оригиналната историја.
• Следење: проверете ги реалните секвенци на настани за превозниците и рутите што се важни за вашиот бизнис.
• Исклучоци: потврдете дека проблемот со испораката што бара дејство стигнува до точниот тим без автоматски да го третира секое невообичаено скенирање како неуспех.
• Опоравување: прекинете барање или webhook endpoint и покажете како апликацијата ги усогласува информациите што недостасуваат.
• Комуникации: потврдете дека само назначениот систем го испраќа секое известување до клиентот.
• Комерцијална соодветност: проценете ги трошоците со очекуваното користење и потврдените дефиниции за наплата од добавувачот.

Правилото за одлука: прво купете ја можноста што недостасува. Ако испраќањето веќе функционира, оценете интеграција за следење без повторно градење на исполнувањето на нарачките. Ако недостасува креирањето етикети, прво решете го извршувањето на испораката. Ако вашата апликација управува со целиот животен циклус на пратката, потврдете ги двете можности и одлучете дали комбинираната или одделената архитектура е полесна за управување од вашиот тим.

ЧПП

Дали shipping API секогаш вклучува следење?

Не. Некои услуги ги вклучуваат двете можности, додека други ги нудат преку одделни endpoints, производи или планови. Дури и кога следењето е вклучено, проверете ги деталите за настаните, начинот на испорака на ажурирањата, поддршката за превозници и условите за користење пред да го третирате како ваше решение за следење по купувањето.

Можам ли да следам пакети чии етикети ги креирал партнер за исполнување на нарачките?

Потенцијално, да. На вашата апликација ѝ се потребни идентификаторите што ги бара интеграцијата за следење, обично бројот за следење и, кога е потребно, идентификатор на превозникот или дополнителни информации за потврда. Потврдете ја поддршката за превозниците на партнерот и уверете се дека броевите за следење сигурно пристигнуваат во вашиот систем.

Дали tracking API ќе предизвика скенирањата од превозникот да се случуваат порано?

Не може да создава физички скенирања од превозникот. Може да ѝ помогне на вашата апликација да ги преземе, организира и дистрибуира информациите достапни преку нејзините извори за следење. Оценувајте го однесувањето при ажурирање со реални пратки, наместо да претпоставувате дека API гарантира непосредна видливост на секое движење.

Дали ми се потребни двајца API добавувачи за да ги користам двете можности?

Не. Ви се потребни двете функции, но не нужно и два добавувачи. Користете еден добавувач кога ги исполнува вашите барања за испорака и следење. Одделете ги кога тоа зачувува работен тек што функционира или исполнува конкретно барање што комбинираната опција не може да го задоволи.

Може ли tracking API да го замени системот за управување со нарачки?

Не. Податоците за следење се влез за управувањето со нарачки, а не замена за распределба на залихи, одлуки за исполнување, обработка на плаќања или записи за нарачки. На вашата апликација сè уште ѝ треба да ја поврзе секоја пратка со точната нарачка и да одлучи како настаните за пратката влијаат врз деловните работни текови.

Извори

• Документација за FedEx Ship API — референца за креирање пратки, етикети и барања во работниот тек за испорака.
• Документација за FedEx tracking API — референца за барања за следење и информации за статусот на пратките.
• 17TRACK Tracking API — официјална референца за производот во категоријата интеграции за следење.
• Документација за 17TRACK API — референца за регистрација на следење, податоци за следење и интеграција на push известувања.