Tracking API проти Shipping API: який із них потрібен вашому стеку електронної комерції (чи обидва)?
Використовуйте shipping API, коли ваш стек електронної комерції має створювати відправлення та генерувати транспортні етикетки. Використовуйте tracking API, коли йому потрібно відстежувати відправлення після передачі перевізнику та перетворювати оновлення перевізника на корисну операційну інформацію або інформацію для клієнтів. Вам потрібні обидві можливості, якщо ваше програмне забезпечення має керувати створенням відправлень і видимістю після покупки, але вам не обов’язково потрібні два постачальники або дві окремі інтеграції.
Рішення приймає той, хто відповідає за архітектуру виконання замовлень: зазвичай керівник операцій електронної комерції, який працює з інженерною командою. Спочатку визначте, що вже обробляє ваш магазин, склад або партнер з виконання замовлень. Додавання ще одного API має усувати конкретну прогалину, а не дублювати робочий процес, який уже функціонує.
У чому різниця між tracking API та shipping API?
Відмінність насамперед полягає в завданні, яке виконує кожен API, а не в жорсткій межі між категоріями продуктів. Платформа доставки може містити кінцеві точки відстеження, тоді як сервіс відстеження може надавати інструменти для сповіщень і оновлень доставки для клієнтів. Оцінюйте задокументовані кінцеві точки та поведінку подій, а не покладайтеся на назву продукту.
| Критерій рішення | Tracking API | Shipping API |
|---|---|---|
| Основне завдання | Отримання або приймання статусу відправлення та подій відстеження. | Створення відправлень і отримання етикеток та пов’язаних транспортних документів. |
| Типові вхідні дані | Номер відстеження, ідентифікатор перевізника та будь-які додаткові необхідні дані про відправлення. | Дані відправника й одержувача, інформація про пакунок, вибір послуги та відповідні митні дані. |
| Типові результати | Статус відправлення, історія подій та інша доступна інформація про доставку. | Ідентифікатори відправлення, етикетки та підтримувані документи. |
| Основний робочий процес | Видимість доставки, обробка винятків і оновлення після покупки. | Передача зі складу та підготовка вихідного відправлення. |
| Чого не слід припускати | Що доступ до відстеження включає створення етикеток або бронювання перевізника. | Що створення етикетки включає необхідну вам деталізацію відстеження та засоби керування сповіщеннями. |
Документація перевізників ілюструє це розділення. FedEx описує створення відправлень у своїй документації Ship API, а можливості відстеження — у своїй документації tracking API. Це приклади різних технічних обов’язків, а не рекомендація обирати певного перевізника.
Створення відправлення — не те саме, що спостереження за його переміщенням
Успішна відповідь на запит створення відправлення повідомляє вашому програмному забезпеченню, що запит на доставку оброблено. Вона не підтверджує, що перевізник фізично отримав посилку. Так само номер відстеження може існувати до того, як у історії відстеження з’явиться інформація про рух.
Тому ваша система керування замовленнями має розрізняти створення етикетки, передачу зі складу, приймання перевізником і доставку. Якщо розглядати все це як одну подію «відправлено», це може призвести до передчасних повідомлень клієнтам і приховати посилки, які фактично ще не залишили склад.
Оберіть можливість, яка усуває ваше поточне вузьке місце
Оберіть shipping API, якщо бракує саме відправлення
Shipping API є доречним початковим рішенням, коли ваш власний застосунок має перетворювати дані замовлення на відправлення. Приклади включають команду складу, яка вручну копіює адреси на портали перевізників, або спеціальну систему керування замовленнями, яка не може генерувати етикетки.
Перш ніж обирати інтеграцію, визначте фактичний робочий процес відправлення. Вам потрібне лише створення відправлень чи також отримання тарифів, скасування, запити на забір, митна документація або операції наприкінці дня? Ці функції можуть бути окремими API, залежати від перевізника або потребувати додаткових дозволів облікового запису. Не припускайте, що продукт із позначкою «shipping API» включає кожну операцію доставки.
Неідеальне рішення як єдиний варіант: інтеграція для створення етикеток, через яку ваша команда обслуговування клієнтів змушена перевіряти окремі вебсайти перевізників. Вона може вирішити проблему відправлення, але майже не змінити видимість доставки.
Оберіть tracking API, якщо створення відправлень уже працює
Tracking API є більш прямим рішенням, коли етикетки вже створюються вашою системою керування складом, партнером з виконання замовлень, маркетплейсом або наявною інтеграцією доставки, але інформація про доставку розпорошена.
У такій ситуації заміна процесу створення етикеток може додати міграційну роботу, не вирішивши головну проблему. Натомість підключіть номери відстеження, згенеровані на попередньому етапі, до рівня видимості, яким можуть користуватися ваша система керування замовленнями, інструменти підтримки та клієнтські комунікації.
У цій категорії 17TRACK Tracking API є доречним варіантом інтеграції. Його офіційна документація API описує реєстрацію номерів відстеження та робочі процеси роботи з даними відстеження, зокрема push-сповіщення. Оцініть ці процеси відповідно до потрібних вам перевізників, типів відправлень і архітектури застосунку. Це стосується рівня відстеження, а не є доказом того, що сервіс замінює інтеграцію для генерування етикеток.
Неідеальне рішення як єдиний варіант: tracking API, якщо ваше програмне забезпечення досі не має способу створювати відправлення, за які воно відповідає під час відправлення. Видимість відстеження не усуває відсутність виконання доставки.
Використовуйте обидва API, якщо ваш застосунок відповідає за відправлення та видимість доставки
Обидві можливості доречні, коли ваш стек має генерувати етикетки, а потім підтримувати надійне уявлення про перебіг відправлення. Вони можуть надходити з однієї платформи, окремих сервісів або комбінації інтеграцій перевізників і рівня відстеження.
Віддавайте перевагу одній інтеграції, якщо її функції доставки та відстеження відповідають задокументованим вимогам без зайвих компромісів. Розглядайте окремі інтеграції, якщо наявний процес доставки варто зберегти або якщо вимоги до відстеження суттєво відрізняються від можливостей цього процесу. Окремий постачальник відстеження не є автоматично кращим: він має виправдовувати додаткові інтеграційні, платіжні та операційні витрати.
Як обидва API вписуються у стек електронної комерції
Практична конструкція зберігає замовлення, відправлення та подію відстеження як окремі записи. Одне замовлення може породити кілька посилок, і кожна посилка може мати власну історію відстеження. Статус замовлення, який бачить клієнт, має формуватися на основі цих записів відправлень, а не замінювати їх.
- Замовлення стає готовим до виконання. Магазин або система керування замовленнями надсилає необхідні дані для виконання відповідальному складу.
- Процес доставки створює відправлення. Застосунок зберігає отримані ідентифікатор відправлення, номер відстеження, перевізника, послугу та посилання на етикетку.
- Склад завершує передачу. Підтвердження складу та приймання перевізником залишаються різними подіями.
- Починається процес відстеження. Ваш застосунок реєструє або надсилає номер відстеження відповідно до вимог обраної інтеграції.
- Оновлення відстеження надходять до вашого застосунку. Вебхуки, опитування або підтримувана комбінація цих способів оновлюють запис відправлення.
- Бізнес-правила визначають подальші дії. Система оновлює статус для клієнта, створює операційне завдання або надсилає повідомлення, коли виконано відповідні умови.
Наприклад, продавцю, який використовує сторонній склад для виконання замовлень, у власному програмному забезпеченні можуть бути потрібні лише кроки з четвертого по шостий. Склад уже відповідає за створення відправлення. Продавцю, який працює з власним складом, може бути потрібен повний процес.
Призначте одного відповідального за кожну подальшу дію
Якщо обидві інтеграції надають оновлення відстеження, визначте, яка система керує сповіщеннями клієнтів і статусом відправлення, що відображається у вашому магазині. Інакше клієнти можуть отримувати дубльовані повідомлення або бачити суперечливі статуси доставки.
Ви можете зберігати вторинні дані для розслідування, не дозволяючи кожному джерелу запускати електронний лист. Зберігайте оригінальну подію перевізника разом із внутрішнім зіставленням статусів, щоб працівники підтримки могли зрозуміти, чому система класифікувала відправлення певним чином.
Порівнюйте операційну відповідність, а не назви функцій
Перевірте перевізників і послуги, якими ви фактично користуєтеся
Підтримка перевізника — це не просте питання «так» або «ні». Сервіс може підтримувати відстеження для певного перевізника, але не підтримувати створення етикеток для нього. Створення етикеток також може залежати від країни походження, налаштування облікового запису перевізника або доступності послуги.
Складіть список тестів на основі фактичних напрямків доставки. Включіть внутрішні посилки, міжнародні відправлення та будь-яку передачу між транспортними партнерами. Підтвердьте потрібну операцію для кожного випадку: створення відправлення, його відстеження або обидві операції. Загальна заява про широке покриття менш корисна, ніж успішні тести послуг, від яких залежить ваш бізнес.
Перевірте значення подій і повноту даних
Для відстеження перевірте, що відбувається до першого сканування, під час винятку доставки, після невдалої спроби доставки та під час доставки. Перевірте, чи містять часові мітки інформацію про часовий пояс і чи залишаються доступними оригінальні описи перевізника.
Не сприймайте нормалізований статус як обіцянку однакових даних для кожного перевізника. Орієнтовні дати доставки, відомості про місцезнаходження та інформація про підтвердження доставки можуть залежати від конкретного перевізника й відправлення. Визначте, як ваш інтерфейс поводитиметься, коли ці поля відсутні.
Перевірте відновлення після збоїв з обох боків
Для доставки особливої уваги потребує тайм-аут під час створення відправлення: запит міг бути успішним, навіть якщо ваш застосунок не отримав відповіді. Перш ніж бездумно повторювати запит, перевірте підтримувані постачальником механізми запобігання дублюванню та узгодження.
Для відстеження протестуйте дубльовані сповіщення, затримані події, невдалу доставку вебхуків і тимчасову недоступність кінцевої точки. Перевірте автентифікацію, поведінку повторних спроб і варіанти відновлення у відповідній документації. Проєктуйте обробку подій так, щоб повторне відтворення оновлення не надсилало те саме повідомлення клієнту ще раз.
Порівнюйте загальну операційну вартість, не припускаючи конкретної моделі ціноутворення
Відокремлюйте плату за API від поштових витрат і витрат на обліковий запис перевізника. Сервіси доставки та відстеження можуть використовувати різні одиниці тарифікації, а комплексна платформа може по-різному об’єднувати можливості. Отримайте комерційну пропозицію або перегляньте відповідний тарифний план для конкретного процесу, який ви плануєте запускати.
Запитайте, як визначається платне використання, чи враховуються невдалі запити, як обробляються повторні надсилання даних відстеження та що відбувається після перевищення ліміту. Врахуйте технічне обслуговування, зусилля служби підтримки та витрати на узгодження двох інтеграцій. Без визначеного набору відправлень і актуальних комерційних умов оголошувати одну категорію дешевшою було б оманливо.
Перегляньте безпеку та зберігання даних
Інтеграції доставки можуть обробляти адреси одержувачів і митну інформацію. Інтеграції відстеження також можуть обробляти ідентифікатори відправлень і пов’язані дані клієнтів. Підтвердьте, які поля є необхідними, обмежте облікові дані потрібним рівнем доступу та не зберігайте секрети у клієнтському коді браузера.
Перевірте зберігання, видалення та контроль доступу відповідно до вимог вашого бізнесу. Зручна інтеграція не повинна вимагати надсилання інформації про клієнта, яка не потрібна для робочого процесу.
Практичний план перевірки перед прийняттям рішення
Проведіть перевірку концепції на репрезентативних відправленнях, а не лише на успішному прикладі з короткого посібника. Узгодьте критерії приймання з операційною, інженерною командами та службою підтримки клієнтів.
- Відправлення: згенеруйте необхідні формати етикеток і підтвердьте, що складське обладнання може їх використовувати.
- Зіставлення замовлень: протестуйте розділені відправлення, кілька посилок і замінні відправлення без втрати початкової історії.
- Відстеження: перевірте реальні послідовності подій для перевізників і маршрутів, важливих для вашого бізнесу.
- Винятки: переконайтеся, що проблема доставки, яка потребує дії, потрапляє до потрібної команди, а кожне нетипове сканування автоматично не трактуєтся як збій.
- Відновлення: перервіть запит або кінцеву точку вебхука та продемонструйте, як застосунок узгоджує відсутню інформацію.
- Комунікації: підтвердьте, що кожне повідомлення клієнту надсилає лише призначена система.
- Комерційна відповідність: оцініть витрати на основі очікуваного використання та підтверджених постачальником визначень тарифікації.
Правило прийняття рішення: спочатку придбайте відсутню можливість. Якщо відправлення вже працює, оцініть інтеграцію відстеження, не перебудовуючи виконання замовлень. Якщо створення етикеток відсутнє, спочатку вирішіть проблему виконання доставки. Якщо ваш застосунок відповідає за повний життєвий цикл відправлення, перевірте обидві можливості та вирішіть, яку архітектуру — об’єднану чи розділену — вашій команді буде легше експлуатувати.
FAQ
Чи завжди shipping API включає відстеження?
Ні. Деякі сервіси включають обидві можливості, тоді як інші надають їх через окремі кінцеві точки, продукти або тарифні плани. Навіть якщо відстеження включено, перевірте деталізацію подій, спосіб доставки оновлень, підтримку перевізників і умови використання, перш ніж вважати його своїм рішенням для відстеження після покупки.
Чи можу я відстежувати посилки, етикетки яких створив партнер з виконання замовлень?
Потенційно так. Вашому застосунку потрібні ідентифікатори, необхідні інтеграції відстеження, зазвичай номер відстеження та, якщо потрібно, ідентифікатор перевізника або додаткова інформація для перевірки. Підтвердьте підтримку перевізників партнера та переконайтеся, що номери відстеження надійно надходять до вашої системи.
Чи змусить tracking API сканування перевізника відбуватися швидше?
Він не може створювати фізичні сканування перевізника. Він може допомогти вашому застосунку отримувати, упорядковувати та поширювати інформацію, доступну через його джерела відстеження. Оцінюйте поведінку оновлень на реальних відправленнях, а не припускайте, що API гарантує миттєву видимість кожного переміщення.
Чи потрібні мені два постачальники API, щоб використовувати обидві можливості?
Ні. Вам потрібні обидві функції, але не обов’язково два постачальники. Використовуйте одного постачальника, якщо він відповідає вашим вимогам до доставки та відстеження. Розділяйте їх, якщо це дає змогу зберегти робочий процес або задовольнити конкретну вимогу, яку об’єднаний варіант не виконує.
Чи може tracking API замінити систему керування замовленнями?
Ні. Дані відстеження є вхідними даними для керування замовленнями, а не заміною розподілу запасів, рішень щодо виконання, обробки платежів або записів замовлень. Ваш застосунок усе одно має пов’язувати кожне відправлення з правильним замовленням і визначати, як події відправлення впливають на бізнес-процеси.
Джерела
- Документація FedEx Ship API — джерело для створення відправлень, етикеток і вимог до процесу доставки.
- Документація FedEx tracking API — джерело для запитів відстеження та інформації про статус відправлення.
- 17TRACK Tracking API — офіційне джерело інформації про продукт у категорії інтеграцій відстеження.
- Документація 17TRACK API — джерело для реєстрації відстеження, даних відстеження та інтеграції push-сповіщень.
