API do śledzenia przesyłek a API wysyłkowe: którego potrzebuje Twój stos e-commerce (czy obu)?

Użyj shipping API, gdy Twój stos ecommerce musi tworzyć przesyłki i generować etykiety wysyłkowe. Użyj tracking API, gdy musi śledzić przesyłki po nadaniu i przekształcać aktualizacje przewoźników w użyteczne informacje operacyjne lub informacje dla klientów. Potrzebujesz obu funkcji, jeśli Twoje oprogramowanie musi zarządzać tworzeniem przesyłek i widocznością po zakupie, ale niekoniecznie potrzebujesz dwóch dostawców ani dwóch oddzielnych integracji.

Decyzja należy do osoby odpowiedzialnej za architekturę realizacji zamówień: zazwyczaj do lidera operacji ecommerce współpracującego z zespołem inżynieryjnym. Zacznij od ustalenia, co już obsługuje Twój sklep, magazyn lub partner realizujący zamówienia. Dodanie kolejnego API powinno uzupełniać konkretną lukę, a nie dublować działający już proces.

Jaka jest różnica między tracking API a shipping API?

Różnica dotyczy przede wszystkim zadania wykonywanego przez każde API, a nie sztywnej granicy między kategoriami produktów. Platforma wysyłkowa może zawierać endpointy śledzenia, a usługa śledzenia może udostępniać narzędzia do powiadomień i aktualizacji dostaw dla klientów. Oceniaj udokumentowane endpointy i sposób obsługi zdarzeń, zamiast kierować się nazwą produktu.

Kryterium decyzji	Tracking API	Shipping API
Główne zadanie	Pobieranie lub odbieranie statusu przesyłki i zdarzeń śledzenia.	Tworzenie przesyłek oraz uzyskiwanie etykiet i powiązanych dokumentów wysyłkowych.
Typowe dane wejściowe	Numer śledzenia, identyfikator przewoźnika i wszelkie dodatkowe wymagane dane przesyłki.	Dane nadawcy i odbiorcy, informacje o paczce, wybór usługi oraz odpowiednie dane celne.
Typowe dane wyjściowe	Status przesyłki, historia zdarzeń i inne dostępne informacje o dostawie.	Identyfikatory przesyłki, etykiety i obsługiwane dokumenty.
Główny proces	Widoczność dostawy, obsługa wyjątków i aktualizacje po zakupie.	Wydanie przesyłki z magazynu i przygotowanie wysyłki.
Czego nie należy zakładać	Że dostęp do śledzenia obejmuje tworzenie etykiet lub rezerwację u przewoźnika.	Że tworzenie etykiet obejmuje poziom szczegółowości śledzenia i mechanizmy powiadomień, których potrzebujesz.

Dokumentacja przewoźników ilustruje ten podział. FedEx opisuje tworzenie przesyłek w swojej dokumentacji Ship API, a funkcje śledzenia w swojej dokumentacji tracking API. Są to przykłady różnych odpowiedzialności technicznych, a nie rekomendacja wyboru konkretnego przewoźnika.

Utworzenie przesyłki to nie to samo co obserwowanie jej przemieszczania

Pomyślna odpowiedź dotycząca utworzenia przesyłki informuje oprogramowanie, że żądanie wysyłki zostało przetworzone. Nie oznacza to, że przewoźnik fizycznie otrzymał paczkę. Podobnie numer śledzenia może istnieć, zanim w historii śledzenia pojawi się informacja o przemieszczaniu.

System zarządzania zamówieniami powinien zatem rozróżniać utworzenie etykiety, przekazanie przesyłki przez magazyn, przyjęcie przez przewoźnika i dostawę. Traktowanie wszystkich tych zdarzeń jako jednego zdarzenia „wysłano” może prowadzić do przedwczesnych wiadomości dla klientów i ukrywać paczki, które w rzeczywistości nie opuściły magazynu.

Wybierz funkcję, która usuwa obecne wąskie gardło

Wybierz shipping API, gdy brakuje obsługi nadania

Shipping API jest właściwym punktem wyjścia, gdy Twoja aplikacja musi przekształcać dane zamówienia w przesyłkę. Przykładem może być zespół magazynowy ręcznie kopiujący adresy do portali przewoźników lub niestandardowy system zarządzania zamówieniami, który nie potrafi generować etykiet.

Przed wyborem integracji określ rzeczywisty proces nadania. Czy potrzebujesz tylko tworzenia przesyłek, czy także pobierania stawek, anulowania, żądań odbioru, dokumentacji celnej lub procesów na koniec dnia? Funkcje te mogą być dostępne w oddzielnych API, zależeć od przewoźnika lub wymagać dodatkowych uprawnień do konta. Nie zakładaj, że produkt oznaczony jako „shipping API” obejmuje każdą operację wysyłkową.

Nie jest idealnym jedynym rozwiązaniem: integracja tworzenia etykiet, która pozostawia zespół obsługi klienta z koniecznością sprawdzania poszczególnych stron przewoźników. Może rozwiązać problem nadania, pozostawiając widoczność dostawy w dużej mierze bez zmian.

Wybierz tracking API, gdy tworzenie przesyłek już działa

Tracking API jest bardziej bezpośrednim rozwiązaniem, gdy etykiety są już tworzone przez system zarządzania magazynem, partnera realizującego zamówienia, marketplace lub istniejącą integrację wysyłkową, ale informacje o dostawie są rozproszone.

W takiej sytuacji zastąpienie procesu etykietowania może zwiększyć nakład pracy związany z migracją, nie rozwiązując głównego problemu. Zamiast tego połącz numery śledzenia generowane w systemie nadrzędnym z warstwą widoczności, z której mogą korzystać system zarządzania zamówieniami, narzędzia wsparcia i komunikacja z klientami.

W tej kategorii 17TRACK Tracking API jest odpowiednią opcją integracji. Jego oficjalna dokumentacja API opisuje rejestrację numerów śledzenia i procesy obsługi danych śledzenia, w tym powiadomienia push. Oceń te procesy pod kątem wymaganych przewoźników, typów przesyłek i architektury aplikacji. Jest to kwestia warstwy śledzenia, a nie dowód, że usługa zastępuje integrację generowania etykiet.

Nie jest idealnym jedynym rozwiązaniem: tracking API, gdy Twoje oprogramowanie nadal nie ma sposobu na tworzenie przesyłek, za których nadanie odpowiada. Widoczność śledzenia nie rozwiązuje problemu braku realizacji wysyłki.

Użyj obu rozwiązań, gdy aplikacja odpowiada za nadanie i widoczność dostawy

Obie funkcje są odpowiednie, gdy Twój stos musi generować etykiety, a następnie utrzymywać wiarygodny obraz postępu przesyłki. Mogą pochodzić z jednej platformy, oddzielnych usług lub połączenia integracji przewoźników z warstwą śledzenia.

Preferuj jedną integrację, gdy jej funkcje wysyłkowe i śledzenia spełniają udokumentowane wymagania bez wymuszania niepotrzebnych kompromisów. Rozważ oddzielne integracje, gdy istniejący proces wysyłkowy warto zachować lub gdy wymagania dotyczące śledzenia znacząco różnią się od tego, co zapewnia ten proces. Oddzielny dostawca śledzenia nie jest automatycznie lepszy; musi uzasadniać dodatkową integrację, rozliczenia i odpowiedzialność operacyjną.

Jak oba API pasują do stosu ecommerce

Praktyczny projekt przechowuje zamówienie, przesyłkę i zdarzenie śledzenia jako oddzielne rekordy. Jedno zamówienie może obejmować kilka paczek, a każda paczka może mieć własną historię śledzenia. Status zamówienia widoczny dla klienta powinien wynikać z tych rekordów przesyłek, a nie je nadpisywać.

1. Zamówienie jest gotowe do realizacji. Sklep lub system zarządzania zamówieniami wysyła wymagane dane realizacji do odpowiedzialnego magazynu.
2. Proces wysyłkowy tworzy przesyłkę. Aplikacja zapisuje zwrócony identyfikator przesyłki, numer śledzenia, przewoźnika, usługę i identyfikator etykiety.
3. Magazyn kończy przekazanie przesyłki. Potwierdzenie magazynu i przyjęcie przez przewoźnika pozostają rozróżnialnymi zdarzeniami.
4. Rozpoczyna się proces śledzenia. Aplikacja rejestruje lub przesyła numer śledzenia zgodnie z wymaganiami wybranej integracji.
5. Aktualizacje śledzenia docierają do aplikacji. Webhooki, odpytywanie lub obsługiwana kombinacja zasila rekord przesyłki.
6. Reguły biznesowe decydują o dalszym działaniu. System aktualizuje status widoczny dla klienta, tworzy zadanie operacyjne lub wysyła wiadomość, gdy zostaną spełnione odpowiednie warunki.

Przykładowo sprzedawca korzystający z zewnętrznego magazynu realizującego zamówienia może potrzebować we własnym oprogramowaniu tylko kroków od czwartego do szóstego. Magazyn już odpowiada za tworzenie przesyłek. Sprzedawca prowadzący własny magazyn może potrzebować pełnego procesu.

Wyznacz jednego właściciela dla każdego działania następczego

Jeśli obie integracje dostarczają aktualizacje śledzenia, wskaż, który system kontroluje powiadomienia dla klientów i status przesyłki wyświetlany w sklepie. W przeciwnym razie klienci mogą otrzymywać zduplikowane wiadomości lub widzieć sprzeczne statusy dostawy.

Możesz zachować dane pomocnicze na potrzeby analizy, nie pozwalając jednak każdemu źródłu wyzwalać wiadomości e-mail. Zachowaj pierwotne zdarzenie przewoźnika obok wewnętrznego mapowania statusu, aby pracownicy wsparcia mogli zrozumieć, dlaczego system sklasyfikował przesyłkę w określony sposób.

Porównuj dopasowanie operacyjne, a nie etykiety funkcji

Zweryfikuj przewoźników i usługi, z których faktycznie korzystasz

Obsługa przewoźników nie jest pojedynczym pytaniem typu tak lub nie. Usługa może obsługiwać śledzenie przesyłek danego przewoźnika, ale nie tworzenie dla niego etykiet. Tworzenie etykiet może również zależeć od kraju nadania, konfiguracji konta przewoźnika lub dostępności usługi.

Utwórz listę testową na podstawie rzeczywistych tras wysyłkowych. Uwzględnij paczki krajowe, przesyłki międzynarodowe i wszelkie przekazania między partnerami transportowymi. Potwierdź wymaganą operację dla każdej z nich: utworzenie przesyłki, śledzenie jej lub oba działania. Szerokie deklaracje dotyczące zakresu obsługi są mniej użyteczne niż pomyślne testy usług, na których polega Twoja firma.

Sprawdź znaczenie zdarzeń i kompletność danych

W przypadku śledzenia przetestuj, co dzieje się przed pierwszym skanem, podczas wyjątku w dostawie, po nieudanej próbie doręczenia i w momencie dostawy. Sprawdź, czy znaczniki czasu zawierają informacje o strefie czasowej oraz czy oryginalne opisy przewoźnika pozostają dostępne.

Nie interpretuj ustandaryzowanego statusu jako obietnicy identycznych danych u każdego przewoźnika. Szacowane daty dostawy, szczegóły lokalizacji i informacje o potwierdzeniu doręczenia mogą zależeć od przewoźnika i przesyłki. Zdecyduj, jak interfejs ma działać, gdy tych pól brakuje.

Sprawdź odzyskiwanie po błędach po obu stronach

W przypadku wysyłki szczególnej uwagi wymaga przekroczenie limitu czasu podczas tworzenia przesyłki: żądanie mogło zakończyć się powodzeniem, nawet jeśli aplikacja nie otrzymała odpowiedzi. Przed bezrefleksyjnym ponawianiem sprawdź obsługiwane przez dostawcę mechanizmy zapobiegania duplikatom i uzgadniania danych.

W przypadku śledzenia przetestuj zduplikowane powiadomienia, opóźnione zdarzenia, nieudaną dostawę webhooka i tymczasowe niedostępności endpointów. Potwierdź w odpowiedniej dokumentacji uwierzytelnianie, sposób ponawiania i opcje odzyskiwania. Zaprojektuj przetwarzanie zdarzeń tak, aby ponowne odtworzenie aktualizacji nie wysyłało tego samego powiadomienia do klienta.

Porównaj całkowity koszt operacyjny bez zakładania modelu cenowego

Oddziel opłaty za API od opłat pocztowych i opłat za konto przewoźnika. Usługi wysyłkowe i śledzenia mogą stosować różne jednostki rozliczeniowe, a zintegrowana platforma może inaczej łączyć funkcje. Uzyskaj wycenę lub sprawdź właściwy plan dla dokładnego procesu, który zamierzasz uruchomić.

Zapytaj, jak definiowane jest użycie podlegające rozliczeniu, czy nieudane żądania są naliczane, jak obsługiwane są ponowne zgłoszenia śledzenia oraz co dzieje się po przekroczeniu limitu. Uwzględnij utrzymanie inżynieryjne, wysiłek związany ze wsparciem oraz koszt utrzymywania spójności dwóch integracji. Bez określonego zestawu przesyłek i aktualnych warunków handlowych stwierdzenie, że jedna kategoria jest tańsza, byłoby mylące.

Przeanalizuj bezpieczeństwo i przechowywanie danych

Integracje wysyłkowe mogą przetwarzać adresy odbiorców i informacje celne. Integracje śledzenia mogą również przetwarzać identyfikatory przesyłek i powiązane dane klientów. Potwierdź, które pola są wymagane, ogranicz dane uwierzytelniające do niezbędnego dostępu i nie umieszczaj sekretów w kodzie po stronie przeglądarki.

Przeanalizuj zasady przechowywania, usuwania i kontroli dostępu pod kątem wymagań swojej firmy. Wygodna integracja nie powinna wymagać wysyłania informacji o kliencie, których proces nie potrzebuje.

Praktyczny plan walidacji przed podjęciem decyzji

Przeprowadź proof of concept z użyciem reprezentatywnych przesyłek, a nie tylko udanego przykładu z przewodnika szybkiego startu. Uzgodnij kryteria akceptacji z zespołami operacyjnym, inżynieryjnym i obsługi klienta.

• Nadanie: wygeneruj wymagane formaty etykiet i potwierdź, że sprzęt magazynowy może ich używać.
• Mapowanie zamówień: przetestuj przesyłki podzielone, wiele paczek i przesyłki zastępcze bez utraty pierwotnej historii.
• Śledzenie: sprawdź rzeczywiste sekwencje zdarzeń dla przewoźników i tras istotnych dla Twojej firmy.
• Wyjątki: zweryfikuj, czy możliwy do podjęcia problem z dostawą dociera do właściwego zespołu bez automatycznego traktowania każdego nietypowego skanu jako awarii.
• Odzyskiwanie: przerwij żądanie lub endpoint webhooka i pokaż, jak aplikacja uzgadnia brakujące informacje.
• Komunikacja: potwierdź, że każde powiadomienie klienta wysyła wyłącznie wyznaczony system.
• Dopasowanie handlowe: oszacuj opłaty na podstawie oczekiwanego użycia i potwierdzonych przez dostawcę zasad rozliczania.

Zasada podejmowania decyzji: najpierw kup brakującą funkcję. Jeśli nadanie już działa, oceń integrację śledzenia bez przebudowy realizacji zamówień. Jeśli brakuje tworzenia etykiet, najpierw rozwiąż problem realizacji wysyłki. Jeśli aplikacja odpowiada za cały cykl życia przesyłki, zweryfikuj obie funkcje i zdecyduj, czy architektura zintegrowana, czy rozdzielona będzie łatwiejsza w obsłudze dla Twojego zespołu.

FAQ

Czy shipping API zawsze obejmuje śledzenie?

Nie. Niektóre usługi obejmują obie funkcje, podczas gdy inne udostępniają je za pośrednictwem oddzielnych endpointów, produktów lub planów. Nawet gdy śledzenie jest uwzględnione, sprawdź szczegółowość zdarzeń, sposób dostarczania aktualizacji, obsługę przewoźników i warunki użytkowania, zanim uznasz je za swoje rozwiązanie śledzenia po zakupie.

Czy mogę śledzić paczki, których etykiety utworzył partner realizujący zamówienia?

Potencjalnie tak. Aplikacja potrzebuje identyfikatorów wymaganych przez integrację śledzenia, zazwyczaj numeru śledzenia oraz, jeśli jest to wymagane, identyfikatora przewoźnika lub dodatkowych informacji weryfikacyjnych. Potwierdź obsługę przewoźników partnera i upewnij się, że numery śledzenia niezawodnie trafiają do Twojego systemu.

Czy tracking API sprawi, że skany przewoźnika będą pojawiać się szybciej?

Nie może tworzyć fizycznych skanów przewoźnika. Może pomóc aplikacji pobierać, porządkować i rozpowszechniać informacje udostępniane przez źródła śledzenia. Oceń sposób aktualizacji na podstawie rzeczywistych przesyłek, zamiast zakładać, że API gwarantuje natychmiastową widoczność każdego przemieszczenia.

Czy potrzebuję dwóch dostawców API, aby korzystać z obu funkcji?

Nie. Potrzebujesz obu funkcji, ale niekoniecznie dwóch dostawców. Użyj jednego dostawcy, jeśli spełnia wymagania dotyczące wysyłki i śledzenia. Rozdziel je, gdy pozwala to zachować działający proces lub spełnić konkretne wymaganie, którego zintegrowana opcja nie spełnia.

Czy tracking API może zastąpić system zarządzania zamówieniami?

Nie. Dane śledzenia są danymi wejściowymi dla zarządzania zamówieniami, a nie zamiennikiem alokacji zapasów, decyzji dotyczących realizacji, obsługi płatności ani rekordów zamówień. Aplikacja nadal musi powiązać każdą przesyłkę z właściwym zamówieniem i zdecydować, jak zdarzenia dotyczące przesyłki wpływają na procesy biznesowe.

Źródła

• Dokumentacja FedEx Ship API — źródło informacji o tworzeniu przesyłek, etykietach i wymaganiach procesu wysyłkowego.
• Dokumentacja FedEx tracking API — źródło informacji o żądaniach śledzenia i danych dotyczących statusu przesyłek.
• 17TRACK Tracking API — oficjalne źródło informacji o produkcie z kategorii integracji śledzenia.
• Dokumentacja 17TRACK API — źródło informacji o rejestracji śledzenia, danych śledzenia i integracji powiadomień push.