OTEP Otevřený protokol Centrum pro vývojáře Domů
Otevřený protokol

OTEP

Otevřete Protokol událostí sledování
Jedna událost. Nekonečné cesty.

Otevřený, na dodavateli nezávislý protokol událostí pro sledování, doručování, fulfillment a logistické operace. Od dopravců a kurýrů přes sklady, schránky, trasy až po budoucí mobilitní sítě poskytuje OTEP společný jazyk pro každou provozní událost.

Mise
Učinit logistické systémy interoperabilními prostřednictvím sdíleného jazyka událostí.

Co je OTEP?

OTEP (Open Tracking Event Protocol) je otevřený, na dodavateli nezávislý protokol pro životní cyklus jakéhokoli sledovatelného předmětu. Iniciovaný a spravovaný společností Superroute, je zdarma k implementaci pro kohokoli. Sjednocuje vlastní doručování, doručování třetích stran, sledování dopravců, potvrzení o doručení, výjimky, skenování uzlů a trajektorii řidiče do jednoho proudu událostí s jedním slovníkem stavů — a je navržen tak, aby se rozšířil na stěhování, rozvoz jídla, skladování a dále.

Problém, který řeší

Sledování je roztříštěné. Každý dopravce pojmenovává pole jinak, každý doručovací kanál žije ve vlastním silu a propojení s globálními standardy znamená opakovanou integraci znovu a znovu.

Roztříštěné slovníky

Každý dopravce používá vlastní stavové kódy a názvy polí. Spotřebitelé píší vlastní mapování pro každou integraci.

Izolované zdroje

Vaši vlastní řidiči, flotily třetích stran a štítkoví dopravci hlásí sledování každý v jiné podobě, takže neexistuje jediná časová osa.

Žádná interoperabilita

Sdílení sledování s partnery na GS1 EPCIS, IATA ONE Record nebo UN/CEFACT znamená vytvářet a udržovat samostatný export pro každý z nich.

Jak to funguje

OTEP je založen na událostech: časová osa událostí je zdrojem pravdy a aktuální stav je jen nejnovější událostí. Každá událost je formována kolem čtyř dimenzí — Co, Kdy, Kde a Proč — stejných dimenzí sdílených EPCIS, ONE Record a UN/CEFACT, takže se tyto standardy stávají jednoduchými projekcemi spíše než paralelními modely. Zdroje, které vystavují pouze aktuální stav (bez historie), jsou zpracovány syntetizováním jedné události na každou změnu, takže chybějící seznam událostí nikdy není překážkou.

What When Where Why

Klíčové funkce

Jednotná časová osa

Vlastní doručování, doručování třetích stran a zásilky dopravců se slučují do jedné seřazené časové osy událostí pro každé sledovací číslo.

Jeden slovník stavů

Normalizovaný životní cyklus kanonických stavových kódů a fází, mapovaný z každého zdroje — žádné dohadování pro jednotlivé dopravce.

Interoperabilita se standardy

Projektujte jakoukoli časovou osu do GS1 EPCIS 2.0, IATA ONE Record nebo UN/CEFACT pomocí jediného parametru požadavku.

Univerzální od základu

Obecný protokol s doménovými profily — dnes balíky; dále stěhování, rozvoz jídla a skladování — nad jednou sdílenou páteří událostí.

Otevřený a nezávislý na dodavateli

Veřejná, verzovaná specifikace, kterou může implementovat kdokoli. Stabilní identifikátory, zveřejněná taxonomie stavů a stavový automat.

Aditivní a bez narušení

Vystaven prostřednictvím nového veřejného API vedle stávajícího. Nic, s čím už integrujete, se nemění.

Koncové body

Veřejné, jen pro čtení, pod stávajícím prefixem /api/v1. Přidejte ?format= pro projekci do externího standardu.

GET
https://api.superlabel.ca/api/v1/otep/trackings/{tracking_number}
Jednotná časová osa OTEP pro sledovací číslo.
GET
https://api.superlabel.ca/api/v1/otep/trackings/{tracking_number}/events
Pouze seznam událostí pro sledovací číslo.
POST
https://api.superlabel.ca/api/v1/otep/trackings/batch
Vyřešte mnoho sledovacích čísel v jednom volání.

Výstupní formáty

Jedna časová osa dovnitř, čtyři reprezentace ven — vybrané pomocí ?format= nebo Accept profilu.

format=otep

Nativní časová osa OTEP (výchozí).

format=epcis

GS1 EPCIS 2.0 ObjectEvents ( JSON-LD ).

format=onerecord

IATA ONE Záznam LogisticsEvents ( JSON-LD ).

format=uncefact

UN/CEFACT události stavu přepravy.

format=otlp

OpenTelemetry OTLP trasy — cesta jako trasa, každá událost jako span.

format=aftership

Objekt sledování kompatibilní s AfterShip s kontrolními body.

format=shopify

Seznam Shopify FulfillmentEvent.

format=amazon

Amazon Shipping (SP-API) historie sledovacích událostí.

format=walmart

Walmart Marketplace stav řádku objednávky a sledování (hrubé).

format=bigcommerce

BigCommerce stav objednávky a sledování (hrubé).

format=magento

Magento stav objednávky a sledování (hrubé).

format=woocommerce

WooCommerce stav objednávky a sledování (hrubé).

format=etsy

Etsy stav účtenky a sledování (hrubé).

format=sensorthings

OGC SensorThings pozorování (IoT).

Životní cyklus stavu

Každá událost se mapuje na kanonický stav seskupený do fází — od přípravy před odesláním přes vyzvednutí, přepravu a vyjetí k doručení až po koncový stav (doručeno, vráceno, odmítnuto nebo zrušeno).

pre_shipment pickup inbound transit out_for_delivery delivered

Otevřený standard

OTEP je publikován jako otevřená specifikace — iniciovaná a spravovaná společností Superroute, zdarma k implementaci pro kohokoli. Není to soukromý formát: obálka události, páteř fází, slovník stavů a stavový automat jsou veřejný, normativní protokol.

Normativní vs. informativní

Protokol (obálka, slovník, stavový automat, standardní mapování) je normativní. Vazby implementátora na jeho vlastní interní systémy jsou informativní a mohou se lišit.

Stabilní a verzovaný

Sémantické verzování. Přidávání kódů nebo profilů je zpětně kompatibilní; význam zveřejněného identifikátoru se nikdy nemění. Verze protokolu cestuje s každou událostí.

Stabilní identifikátory

Kódy jsou adresovány jako otep:<profile>:<code> a fáze jako otep:phase:<name>, takže slovník zůstává globálně jednoznačný napříč implementátory.

Otevřený a nezávislý na dodavateli

Veřejná specifikace, kterou může přijmout kdokoli, s otevřenou licencí a veřejným procesem rozšíření — navrhujte nové profily a kódy místo forkování.

Vytvořte kompatibilní implementaci

Producenti a spotřebitelé se integrují jednou proti protokolu, ne jednou za každého dopravce. Čtyři kroky ke konformní implementaci.

1. Modelujte události jako Co / Kdy / Kde / Proč

Vyzařujte každou událost s jejím předmětem (Co), časem výskytu a záznamu (Kdy), umístěním (Kde) a kanonickým stavem plus volitelným důvodem (Proč). Každé pole kromě předmětu, času a stavu je volitelné — vyplňte to, co máte.

2. Mapujte na kanonický slovník

Přeložte své surové stavové kódy na stavové kódy a fáze OTEP. Zdroje, které vystavují pouze aktuální stav, syntetizují jednu událost na každou změnu.

3. Respektujte stavový automat

Seřaďte události podle času výskytu, tolerujte příchod mimo pořadí a považujte delivered / returned / rejected / cancelled za koncové. Označte experimentální kódy prefixem x- dokud nejsou registrovány.

4. Konzumujte nebo projektujte

Čtěte nativní OTEP nebo požádejte o projekci EPCIS / ONE Record / UN-CEFACT — stejná událost, jeden parametr. Nový výstupní standard je jen nový serializér.

Úrovně konformity

Level 1

Úroveň 1 — vyzařujte univerzální kódy, fáze a platné stavové přechody.

Level 2

Úroveň 2 — navíc vyzařujte kódy specifické pro profil a alespoň jednu projekci do externího standardu.

Mezinárodní interoperabilita

Čtyři dimenze OTEP se shodují pole po poli s hlavními globálními standardy, takže každý se stává výstupní projekcí spíše než paralelní integrací.

GS1 EPCIS 2.0

Každá událost OTEP se stává ObjectEvent; stav se mapuje na CBV bizStep + disposition; umístění na readPoint. Stabilní standardní URN.

IATA ONE Record

Každá událost se stává LogisticsEvent s eventCode a eventTimeType; časová osa se připojuje k Shipment / Piece.

UN/CEFACT

Každá událost se stává TransportEvent s kódem stavu přepravy pod Consignment.

Mapování polí (OTEP → standard)
OTEPGS1 EPCIS 2.0IATA ONE RecordUN/CEFACT
occurred_ateventTimeeventDateOccurrence Date/Time
status_codebizStep + dispositioneventCodeTransport status code
locationreadPoint / bizLocationrecordedAtLocationLocation
subjectepcListlinkedObjectConsignment
incident_reasondispositionevent remarkStatus reason code

Hodnoty EPCIS CBV jsou stabilní standardní URN. Kódové hodnoty ONE Record a UN/CEFACT jsou nejvhodnější shodou pro poslední míli a měly by být ověřeny proti oficiálním seznamům kódů před externím použitím.

Budoucí interoperabilita Cestovní mapa

OTEP je navržen tak, aby neustále vstřebával standardy. Tyto jsou na cestovní mapě interoperability.

MCP AI
Vystavte časové osy OTEP AI asistentům přes MCP pro sledování v přirozeném jazyce.
OGC SensorThings IoT
Přijímejte OGC SensorThings IoT telemetrii (teplota, poloha, otřesy) jako senzorové události OTEP.

V hodnocení: Další tržiště (TikTok Shop, Temu, Shein a další) jsou hodnocena a budou přidána, jakmile se jejich veřejná fulfillment API stabilizují.

Nemůžete OTEP zatím přijmout? Stejně buďme interoperabilní.

I když z jakéhokoli důvodu nemůžete použít standard OTEP přímo, srdečně vás vítáme, abyste nám vyšli vstříc na půl cesty — a rádi budeme spolupracovat na úrovni interoperability.

Zdroje pro vývojáře

Vše, co potřebujete k vytvoření a ověření integrace konformní s OTEP — offline specifikace, strojově čitelné schéma a kódovník, živý validátor konformity, MCP konfigurace a vývojová dovednost.

Číst online

Offline soubory ke stažení

Začněte stavět

Koncové body OTEP jsou aktivní pod /api/v1/otep. Prozkoumejte je v referenci REST API.

Otevřít referenci API