An open, vendor-neutral event protocol for tracking, delivery, fulfillment, and logistics operations. From carriers and couriers to warehouses, lockers, routes, and future mobility networks, OTEP provides a common language for every operational event.
OTEP (Open Tracking Event Protocol) is an open, vendor-neutral protocol for the lifecycle of any trackable subject. Initiated and stewarded by Superroute, it is free for anyone to implement. It unifies self-delivery, third-party delivery, carrier tracking, proof-of-delivery, exceptions, node scans and driver trajectory into one event stream with one status vocabulary — and is designed to extend to moving, food delivery, storage and beyond.
Tracking is fragmented. Every carrier names fields differently, every delivery channel lives in its own silo, and connecting to global standards means re-integrating again and again.
Each carrier uses its own status codes and field names. Consumers write bespoke mapping for every integration.
Your own drivers, third-party fleets and label carriers each report tracking in a different shape, so no single timeline exists.
Sharing tracking with partners on GS1 EPCIS, IATA ONE Record or UN/CEFACT means building and maintaining a separate export for each.
OTEP is event-sourced: the event timeline is the source of truth and the current status is just the latest event. Every event is shaped around four dimensions — What, When, Where and Why — the same dimensions shared by EPCIS, ONE Record and UN/CEFACT, so those standards become simple projections rather than parallel models. Sources that expose only a current status (no history) are handled by synthesizing one event per change, so a missing event list is never a blocker.
Self-delivery, third-party delivery and carrier shipments merge into one ordered event timeline per tracking number.
A normalized lifecycle of canonical status codes and phases, mapped from every source — no more per-carrier guesswork.
Project any timeline to GS1 EPCIS 2.0, IATA ONE Record or UN/CEFACT with a single request parameter.
A general protocol with domain profiles — parcel today; moving, food delivery and storage next — over one shared event spine.
A public, versioned specification anyone can implement. Stable identifiers, a published status taxonomy and a state machine.
Exposed through a new public API alongside the existing one. Nothing you already integrate with changes.
Public, read-only, under the existing /api/v1 prefix. Add ?format= for an external-standard projection.
One timeline in, four representations out — chosen by ?format= or an Accept profile.
Native OTEP timeline (default).
GS1 EPCIS 2.0 ObjectEvents (JSON-LD).
IATA ONE Record LogisticsEvents (JSON-LD).
UN/CEFACT transport status events.
OpenTelemetry OTLP traces — the journey as a trace, each event a span.
AfterShip-compatible tracking object with checkpoints.
Shopify FulfillmentEvent list.
Amazon Shipping (SP-API) tracking event history.
Walmart Marketplace order-line status and tracking (coarse).
BigCommerce order status and tracking (coarse).
Magento order state and tracking (coarse).
WooCommerce order status and tracking (coarse).
Etsy receipt status and tracking (coarse).
OGC SensorThings observations (IoT).
Every event maps to a canonical status grouped into phases — from pre-shipment through pickup, transit and out-for-delivery to a terminal state (delivered, returned, rejected or cancelled).
OTEP is published as an open specification — initiated and stewarded by Superroute, free for anyone to implement. It is not a private format: the event envelope, the phase spine, the status vocabulary and the state machine are the public, normative protocol.
The protocol (envelope, vocabulary, state machine, standard mappings) is normative. An implementer's bindings to its own internal systems are informative and may differ.
Semantic versioning. Adding codes or profiles is backward-compatible; a published identifier's meaning never changes. The protocol version travels with every event.
Codes are addressed as otep:<profile>:<code> and phases as otep:phase:<name>, so vocabulary stays globally unambiguous across implementers.
A public specification any party can adopt, with an open license and a public extension process — propose new profiles and codes instead of forking.
Producers and consumers integrate once against the protocol, not once per carrier. Four steps to a conformant implementation.
Emit each event with its subject (What), occurrence and record time (When), location (Where) and a canonical status plus optional reason (Why). Every field except subject, time and status is optional — fill what you have.
Translate your raw status codes to OTEP status codes and phases. Sources that expose only a current status synthesize one event per change.
Order events by occurrence time, tolerate out-of-order arrival, and treat delivered / returned / rejected / cancelled as terminal. Mark experimental codes with an x- prefix until registered.
Read native OTEP, or request an EPCIS / ONE Record / UN-CEFACT projection — same event, one parameter. A new output standard is just a new serializer.
Level 1 — emit the universal codes, phases and valid state transitions.
Level 2 — additionally emit profile-specific codes and at least one external-standard projection.
OTEP's four dimensions line up field-for-field with the major global standards, so each becomes an output projection rather than a parallel integration.
Each OTEP event becomes an ObjectEvent; status maps to CBV bizStep + disposition; location to readPoint. Stable standard URNs.
Each event becomes a LogisticsEvent with an eventCode and eventTimeType; the timeline attaches to a Shipment / Piece.
Each event becomes a TransportEvent with a transport status code under a 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 values are stable standard URNs. ONE Record and UN/CEFACT code values are best-fit for last-mile and should be validated against the official code lists before external use.
OTEP is built to keep absorbing standards. These are on the interoperability roadmap.
Under evaluation: Other marketplaces (TikTok Shop, Temu, Shein, and more) are being evaluated and will be added as their public fulfillment APIs stabilize.
Even if you can't use the OTEP standard directly, for any reason, we warmly welcome you to meet us partway — and we're glad to collaborate at the interoperability level.
otep_status field to your API responses and return values — one normalized, carrier-independent status alongside your own existing fields. It's purely additive and won't affect your current consumers.Everything you need to build and verify an OTEP-conformant integration — offline spec, machine-readable schema and codebook, a live conformance validator, an MCP config, and a development skill.
Read the full normative protocol spec in your browser.
View onlineBrowse every status code, phase and mapping online.
View onlineWorked, copy-pasteable integration examples.
View onlinePOST a timeline to check it conforms; get back the exact errors and warnings.
POSThttps://api.superroute.ca/api/v1/otep/validate
The full normative protocol spec, offline.
Download .mdPrint-ready PDF of the protocol spec.
Download .pdfValidate your payloads against the OTEP timeline schema.
Download .jsonThe complete, accurate status codes, phases, bridges and external mappings — generated from the implementation.
Download .jsonConnect an AI assistant to the OTEP tools for assisted development.
Download .jsonA ready-to-use skill that guides building OTEP-conformant code.
Download .mdOTEP endpoints are live under /api/v1/otep. Explore them in the REST API reference.
Open API Reference