Otwarty, niezależny od dostawcy protokół zdarzeń do śledzenia, doręczania, realizacji zamówień i operacji logistycznych. Od przewoźników i kurierów po magazyny, paczkomaty, trasy i przyszłe sieci mobilności — OTEP zapewnia wspólny język dla każdego zdarzenia operacyjnego.
OTEP (Open Tracking Event Protocol) to otwarty, niezależny od dostawcy protokół obejmujący cykl życia dowolnego śledzonego obiektu. Zainicjowany i nadzorowany przez Superroute, jest bezpłatny do wdrożenia dla każdego. Ujednolica dostawę własną, dostawę zewnętrzną, śledzenie przewoźnika, potwierdzenie doręczenia, wyjątki, skany w węzłach i trajektorię kierowcy w jednym strumieniu zdarzeń z jednym słownikiem statusów — i został zaprojektowany tak, aby objąć przeprowadzki, dostawę jedzenia, przechowywanie i nie tylko.
Śledzenie jest rozproszone. Każdy przewoźnik inaczej nazywa pola, każdy kanał dostawy żyje we własnym silosie, a połączenie z globalnymi standardami oznacza wciąż powtarzaną integrację.
Każdy przewoźnik używa własnych kodów statusów i nazw pól. Odbiorcy piszą indywidualne mapowania dla każdej integracji.
Twoi własni kierowcy, floty zewnętrzne i przewoźnicy etykiet — każdy raportuje śledzenie w innej formie, więc nie istnieje jedna oś czasu.
Udostępnianie śledzenia partnerom w GS1 EPCIS, IATA ONE Record lub UN/CEFACT oznacza budowanie i utrzymywanie osobnego eksportu dla każdego z nich.
OTEP jest oparty na zdarzeniach: oś czasu zdarzeń jest źródłem prawdy, a bieżący status to po prostu najnowsze zdarzenie. Każde zdarzenie jest zbudowane wokół czterech wymiarów — Co, Kiedy, Gdzie i Dlaczego — tych samych wymiarów, które dzielą EPCIS, ONE Record i UN/CEFACT, dzięki czemu te standardy stają się prostymi projekcjami, a nie równoległymi modelami. Źródła, które udostępniają tylko bieżący status (bez historii), są obsługiwane przez syntetyzowanie jednego zdarzenia na każdą zmianę, więc brak listy zdarzeń nigdy nie jest przeszkodą.
Dostawa własna, dostawa zewnętrzna i przesyłki przewoźników łączą się w jedną uporządkowaną oś czasu zdarzeń dla każdego numeru śledzenia.
Znormalizowany cykl życia kanonicznych kodów statusów i faz, zmapowany z każdego źródła — koniec ze zgadywaniem dla każdego przewoźnika.
Rzutuj dowolną oś czasu na GS1 EPCIS 2.0, IATA ONE Record lub UN/CEFACT za pomocą jednego parametru żądania.
Ogólny protokół z profilami dziedzinowymi — dziś paczki; w przyszłości przeprowadzki, dostawa jedzenia i przechowywanie — na jednym wspólnym kręgosłupie zdarzeń.
Publiczna, wersjonowana specyfikacja, którą każdy może wdrożyć. Stabilne identyfikatory, opublikowana taksonomia statusów i maszyna stanów.
Udostępniany przez nowe publiczne API obok istniejącego. Nic, z czym już się integrujesz, się nie zmienia.
Publiczne, tylko do odczytu, pod istniejącym prefiksem /api/v1. Dodaj ?format= dla projekcji w standardzie zewnętrznym.
Jedna oś czasu na wejściu, cztery reprezentacje na wyjściu — wybierane przez ?format= lub profil Accept.
Natywna oś czasu OTEP (domyślnie).
GS1 EPCIS 2.0 Zdarzenia obiektowe ( JSON-LD ).
IATA ONE Rejestruj zdarzenia logistyczne ( JSON-LD ).
Zdarzenia statusu transportu UN/CEFACT.
Ślady OpenTelemetry OTLP — podróż jako ślad, każde zdarzenie jako span.
Obiekt śledzenia zgodny z AfterShip z punktami kontrolnymi.
Lista Shopify FulfillmentEvent.
Historia zdarzeń śledzenia Amazon Shipping (SP-API).
Status pozycji zamówienia i śledzenie Walmart Marketplace (przybliżone).
Status zamówienia i śledzenie BigCommerce (przybliżone).
Stan zamówienia i śledzenie Magento (przybliżone).
Status zamówienia i śledzenie WooCommerce (przybliżone).
Status potwierdzenia i śledzenie Etsy (przybliżone).
Obserwacje OGC SensorThings (IoT).
Każde zdarzenie mapuje się na kanoniczny status pogrupowany w fazy — od przed wysyłką, przez odbiór, tranzyt i dostarczanie, aż po stan końcowy (doręczone, zwrócone, odrzucone lub anulowane).
OTEP jest publikowany jako otwarta specyfikacja — zainicjowana i nadzorowana przez Superroute, bezpłatna do wdrożenia dla każdego. Nie jest to format prywatny: koperta zdarzenia, kręgosłup faz, słownik statusów i maszyna stanów stanowią publiczny, normatywny protokół.
Protokół (koperta, słownik, maszyna stanów, standardowe mapowania) jest normatywny. Powiązania implementatora z jego własnymi systemami wewnętrznymi są informacyjne i mogą się różnić.
Wersjonowanie semantyczne. Dodawanie kodów lub profili jest wstecznie kompatybilne; znaczenie opublikowanego identyfikatora nigdy się nie zmienia. Wersja protokołu podróżuje z każdym zdarzeniem.
Kody są adresowane jako otep:<profile>:<code>, a fazy jako otep:phase:<name>, dzięki czemu słownik pozostaje globalnie jednoznaczny dla wszystkich implementatorów.
Publiczna specyfikacja, którą może przyjąć każda strona, z otwartą licencją i publicznym procesem rozszerzania — proponuj nowe profile i kody zamiast tworzyć rozgałęzienia.
Producenci i odbiorcy integrują się raz z protokołem, a nie raz na przewoźnika. Cztery kroki do zgodnej implementacji.
Emituj każde zdarzenie z jego podmiotem (Co), czasem wystąpienia i zapisu (Kiedy), lokalizacją (Gdzie) oraz kanonicznym statusem i opcjonalnym powodem (Dlaczego). Każde pole oprócz podmiotu, czasu i statusu jest opcjonalne — wypełnij to, co masz.
Przetłumacz swoje surowe kody statusów na kody statusów i fazy OTEP. Źródła udostępniające tylko bieżący status syntetyzują jedno zdarzenie na każdą zmianę.
Porządkuj zdarzenia według czasu wystąpienia, toleruj przybycie poza kolejnością i traktuj delivered / returned / rejected / cancelled jako stany końcowe. Oznaczaj kody eksperymentalne prefiksem x- aż do ich rejestracji.
Odczytuj natywny OTEP lub żądaj projekcji EPCIS / ONE Record / UN-CEFACT — to samo zdarzenie, jeden parametr. Nowy standard wyjściowy to po prostu nowy serializator.
Poziom 1 — emituj uniwersalne kody, fazy i prawidłowe przejścia stanów.
Poziom 2 — dodatkowo emituj kody specyficzne dla profilu oraz co najmniej jedną projekcję w standardzie zewnętrznym.
Cztery wymiary OTEP odpowiadają pole w pole głównym globalnym standardom, więc każdy z nich staje się projekcją wyjściową, a nie równoległą integracją.
Każde zdarzenie OTEP staje się ObjectEvent; status mapuje się na CBV bizStep + disposition; lokalizacja na readPoint. Stabilne standardowe URN-y.
Każde zdarzenie staje się LogisticsEvent z eventCode i eventTimeType; oś czasu jest dołączana do Shipment / Piece.
Każde zdarzenie staje się TransportEvent z kodem statusu transportu w ramach Consignment.
| OTEP | GS1 EPCIS 2.0 | IATA ONE Record | UN/CEFACT |
|---|---|---|---|
| occurred_at | eventTime | eventDate | Occurrence Date/Time |
| status_code | bizStep + disposition | eventCode | Transport status code |
| location | readPoint / bizLocation | recordedAtLocation | Location |
| subject | epcList | linkedObject | Consignment |
| incident_reason | disposition | event remark | Status reason code |
Wartości EPCIS CBV to stabilne standardowe URN-y. Wartości kodów ONE Record i UN/CEFACT są najlepszym dopasowaniem dla ostatniej mili i powinny zostać zweryfikowane względem oficjalnych list kodów przed użyciem zewnętrznym.
OTEP został stworzony, aby nieustannie przyswajać standardy. Oto, co znajduje się na mapie drogowej interoperacyjności.
W ocenie: Inne platformy handlowe (TikTok Shop, Temu, Shein i więcej) są oceniane i zostaną dodane, gdy ich publiczne API realizacji zamówień się ustabilizują.
Nawet jeśli z jakiegokolwiek powodu nie możesz bezpośrednio korzystać ze standardu OTEP, serdecznie zapraszamy do spotkania się w połowie drogi — i chętnie współpracujemy na poziomie interoperacyjności.
otep_status do swoich odpowiedzi API i zwracanych wartości — jeden znormalizowany, niezależny od przewoźnika status obok własnych istniejących pól. Jest to czysto addytywne i nie wpłynie na obecnych odbiorców.Wszystko, czego potrzebujesz, aby zbudować i zweryfikować integrację zgodną z OTEP — specyfikacja offline, schemat i kodeks do odczytu maszynowego, działający walidator zgodności, konfiguracja MCP oraz umiejętność deweloperska.
Przeczytaj pełną normatywną specyfikację protokołu w przeglądarce.
Zobacz onlinePrzeglądaj online każdy kod statusu, fazę i mapowanie.
Zobacz onlineGotowe przykłady integracji do skopiowania.
Zobacz onlineWyślij (POST) oś czasu, aby sprawdzić jej zgodność; otrzymasz dokładne błędy i ostrzeżenia.
POSThttps://api.superlabel.ca/api/v1/otep/validate
Pełna normatywna specyfikacja protokołu, offline.
Pobierz .mdGotowy do druku PDF specyfikacji protokołu.
Pobierz .pdfWaliduj swoje ładunki względem schematu osi czasu OTEP.
Pobierz .jsonKompletne, dokładne kody statusów, fazy, pomosty i mapowania zewnętrzne — wygenerowane z implementacji.
Pobierz .jsonPołącz asystenta AI z narzędziami OTEP, aby wspomagać rozwój.
Pobierz .jsonGotowa do użycia umiejętność, która prowadzi przez budowanie kodu zgodnego z OTEP.
Pobierz .mdPunkty końcowe OTEP są dostępne pod /api/v1/otep. Poznaj je w dokumentacji REST API.
Otwórz dokumentację API