Ein offenes, herstellerneutrales Ereignisprotokoll für Sendungsverfolgung, Zustellung, Fulfillment und Logistikabläufe. Von Spediteuren und Kurieren über Lager, Schließfächer und Routen bis hin zu künftigen Mobilitätsnetzen bietet OTEP eine gemeinsame Sprache für jedes operative Ereignis.
OTEP (Open Tracking Event Protocol) ist ein offenes, herstellerneutrales Protokoll für den Lebenszyklus jedes verfolgbaren Objekts. Initiiert und betreut von Superroute, steht es jedem zur freien Implementierung offen. Es vereint Eigenzustellung, Drittanbieterzustellung, Carrier-Tracking, Zustellnachweis, Ausnahmen, Knoten-Scans und Fahrertrajektorien in einem einzigen Ereignisstrom mit einem einheitlichen Statusvokabular — und ist darauf ausgelegt, sich auf Umzüge, Lebensmittellieferung, Lagerung und darüber hinaus zu erweitern.
Sendungsverfolgung ist fragmentiert. Jeder Carrier benennt Felder anders, jeder Zustellkanal lebt in seinem eigenen Silo, und die Anbindung an globale Standards bedeutet, immer wieder neu zu integrieren.
Jeder Carrier verwendet eigene Statuscodes und Feldnamen. Verbraucher schreiben für jede Integration eine maßgeschneiderte Zuordnung.
Ihre eigenen Fahrer, Drittanbieterflotten und Label-Carrier melden Tracking jeweils in einer anderen Form, sodass keine einheitliche Zeitleiste existiert.
Tracking mit Partnern auf GS1 EPCIS, IATA ONE Record oder UN/CEFACT zu teilen bedeutet, für jeden einen separaten Export zu erstellen und zu pflegen.
OTEP ist ereignisbasiert (Event-Sourced): Die Ereignis-Zeitleiste ist die Quelle der Wahrheit und der aktuelle Status ist lediglich das jüngste Ereignis. Jedes Ereignis ist um vier Dimensionen herum aufgebaut — Was, Wann, Wo und Warum — dieselben Dimensionen, die EPCIS, ONE Record und UN/CEFACT teilen, sodass diese Standards zu einfachen Projektionen statt zu parallelen Modellen werden. Quellen, die nur einen aktuellen Status (ohne Verlauf) bereitstellen, werden behandelt, indem pro Änderung ein Ereignis synthetisiert wird, sodass eine fehlende Ereignisliste niemals ein Hindernis ist.
Eigenzustellung, Drittanbieterzustellung und Carrier-Sendungen verschmelzen pro Sendungsnummer zu einer geordneten Ereignis-Zeitleiste.
Ein normalisierter Lebenszyklus kanonischer Statuscodes und Phasen, zugeordnet von jeder Quelle — kein Rätselraten mehr pro Carrier.
Projizieren Sie jede Zeitleiste mit einem einzigen Anfrageparameter auf GS1 EPCIS 2.0, IATA ONE Record oder UN/CEFACT.
Ein allgemeines Protokoll mit Domänenprofilen — heute Paket; als Nächstes Umzug, Lebensmittellieferung und Lagerung — über ein gemeinsames Ereignisrückgrat.
Eine öffentliche, versionierte Spezifikation, die jeder implementieren kann. Stabile Bezeichner, eine veröffentlichte Statustaxonomie und ein Zustandsautomat.
Bereitgestellt über eine neue öffentliche API neben der bestehenden. An allem, was Sie bereits integriert haben, ändert sich nichts.
Öffentlich, schreibgeschützt, unter dem bestehenden /api/v1-Präfix. Fügen Sie ?format= für eine Projektion auf einen externen Standard hinzu.
Eine Zeitleiste hinein, vier Repräsentationen heraus — ausgewählt über ?format= oder ein Accept-Profil.
Native OTEP-Zeitleiste (Standard).
GS1 EPCIS 2.0 ObjectEvents ( JSON-LD ).
IATA ONE Logistikereignisse aufzeichnen ( JSON-LD ).
UN/CEFACT-Transportstatusereignisse.
OpenTelemetry OTLP-Traces — die Reise als Trace, jedes Ereignis ein Span.
AfterShip-kompatibles Tracking-Objekt mit Kontrollpunkten.
Shopify FulfillmentEvent-Liste.
Amazon Shipping (SP-API) Tracking-Ereignisverlauf.
Walmart Marketplace Bestellpositions-Status und Tracking (grob).
BigCommerce Bestellstatus und Tracking (grob).
Magento Bestellzustand und Tracking (grob).
WooCommerce Bestellstatus und Tracking (grob).
Etsy Beleg-Status und Tracking (grob).
OGC SensorThings Beobachtungen (IoT).
Jedes Ereignis wird einem kanonischen Status zugeordnet, der in Phasen gruppiert ist — vom Vorversand über Abholung, Transport und Auslieferung bis zu einem Endzustand (delivered, returned, rejected oder cancelled).
OTEP wird als offene Spezifikation veröffentlicht — initiiert und betreut von Superroute, steht es jedem zur freien Implementierung offen. Es ist kein privates Format: Der Ereignisumschlag, das Phasenrückgrat, das Statusvokabular und der Zustandsautomat bilden das öffentliche, normative Protokoll.
Das Protokoll (Umschlag, Vokabular, Zustandsautomat, Standardzuordnungen) ist normativ. Die Anbindungen eines Implementierers an seine eigenen internen Systeme sind informativ und können abweichen.
Semantische Versionierung. Das Hinzufügen von Codes oder Profilen ist abwärtskompatibel; die Bedeutung eines veröffentlichten Bezeichners ändert sich nie. Die Protokollversion begleitet jedes Ereignis.
Codes werden als otep:<profile>:<code> und Phasen als otep:phase:<name> adressiert, sodass das Vokabular über alle Implementierer hinweg global eindeutig bleibt.
Eine öffentliche Spezifikation, die jede Partei übernehmen kann, mit einer offenen Lizenz und einem öffentlichen Erweiterungsprozess — schlagen Sie neue Profile und Codes vor, anstatt zu forken.
Produzenten und Verbraucher integrieren einmal gegen das Protokoll, nicht einmal pro Carrier. Vier Schritte zu einer konformen Implementierung.
Senden Sie jedes Ereignis mit seinem Subjekt (Was), Eintritts- und Aufzeichnungszeitpunkt (Wann), Standort (Wo) sowie einem kanonischen Status und optionalem Grund (Warum). Jedes Feld außer Subjekt, Zeit und Status ist optional — füllen Sie aus, was Sie haben.
Übersetzen Sie Ihre Rohstatuscodes in OTEP-Statuscodes und Phasen. Quellen, die nur einen aktuellen Status bereitstellen, synthetisieren pro Änderung ein Ereignis.
Ordnen Sie Ereignisse nach Eintrittszeit, tolerieren Sie verspätete Reihenfolge und behandeln Sie delivered / returned / rejected / cancelled als terminal. Kennzeichnen Sie experimentelle Codes mit einem x-Präfix, bis sie registriert sind.
Lesen Sie natives OTEP oder fordern Sie eine EPCIS- / ONE Record- / UN-CEFACT-Projektion an — dasselbe Ereignis, ein Parameter. Ein neuer Ausgabestandard ist lediglich ein neuer Serialisierer.
Stufe 1 — gibt die universellen Codes, Phasen und gültigen Zustandsübergänge aus.
Stufe 2 — gibt zusätzlich profilspezifische Codes und mindestens eine Projektion auf einen externen Standard aus.
Die vier Dimensionen von OTEP decken sich Feld für Feld mit den großen globalen Standards, sodass jeder zu einer Ausgabeprojektion statt einer parallelen Integration wird.
Jedes OTEP-Ereignis wird zu einem ObjectEvent; der Status wird auf CBV bizStep + disposition abgebildet; der Standort auf readPoint. Stabile Standard-URNs.
Jedes Ereignis wird zu einem LogisticsEvent mit einem eventCode und eventTimeType; die Zeitleiste wird an ein Shipment / Piece angehängt.
Jedes Ereignis wird zu einem TransportEvent mit einem Transportstatuscode unter einer 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 |
EPCIS CBV-Werte sind stabile Standard-URNs. ONE Record- und UN/CEFACT-Codewerte sind Best-Fit für die letzte Meile und sollten vor externer Nutzung gegen die offiziellen Codelisten validiert werden.
OTEP ist darauf ausgelegt, weiterhin Standards zu absorbieren. Diese stehen auf der Interoperabilitäts-Roadmap.
In Bewertung: Weitere Marktplätze (TikTok Shop, Temu, Shein und mehr) werden bewertet und hinzugefügt, sobald sich ihre öffentlichen Fulfillment-APIs stabilisieren.
Selbst wenn Sie den OTEP-Standard aus irgendeinem Grund nicht direkt verwenden können, heißen wir Sie herzlich willkommen, uns auf halbem Weg entgegenzukommen — und wir arbeiten gerne auf der Interoperabilitätsebene zusammen.
otep_status-Feld hinzu — einen normalisierten, carrierunabhängigen Status neben Ihren eigenen bestehenden Feldern. Es ist rein additiv und beeinträchtigt Ihre aktuellen Verbraucher nicht.Alles, was Sie zum Erstellen und Verifizieren einer OTEP-konformen Integration benötigen — Offline-Spezifikation, maschinenlesbares Schema und Codebuch, ein Live-Konformitätsvalidator, eine MCP-Konfiguration und ein Entwicklungs-Skill.
Lies die vollständige normative Protokollspezifikation im Browser.
Online ansehenDurchsuche jeden Statuscode, jede Phase und jedes Mapping online.
Online ansehenFertige, kopierbare Integrationsbeispiele.
Online ansehenPOSTen Sie eine Zeitleiste, um ihre Konformität zu prüfen; Sie erhalten die genauen Fehler und Warnungen zurück.
POSThttps://api.superlabel.ca/api/v1/otep/validate
Die vollständige normative Protokollspezifikation, offline.
Herunterladen .mdDruckfertiges PDF der Protokollspezifikation.
Herunterladen .pdfValidieren Sie Ihre Payloads gegen das OTEP-Zeitleistenschema.
Herunterladen .jsonDie vollständigen, akkuraten Statuscodes, Phasen, Brücken und externen Zuordnungen — generiert aus der Implementierung.
Herunterladen .jsonVerbinden Sie einen KI-Assistenten mit den OTEP-Tools für unterstützte Entwicklung.
Herunterladen .jsonEin einsatzbereiter Skill, der beim Erstellen von OTEP-konformem Code anleitet.
Herunterladen .mdOTEP-Endpunkte sind unter /api/v1/otep live. Erkunden Sie sie in der REST-API-Referenz.
API-Referenz öffnen