一个开放、厂商中立的事件协议，用于跟踪、配送、履约和物流运营。从承运商和快递员到仓库、储物柜、路线以及未来的出行网络，OTEP 为每一个运营事件提供统一的语言。
OTEP（Open Tracking Event Protocol）是一个开放、厂商中立的协议，覆盖任何可跟踪主体的整个生命周期。它由 Superroute 发起并维护，任何人都可以免费实现。它将自配送、第三方配送、承运商跟踪、配送证明、异常、节点扫描和司机轨迹统一为一条事件流，使用一套状态词汇——并且其设计可扩展到搬家、外卖、仓储等更多场景。
跟踪是碎片化的。每家承运商对字段的命名各不相同，每条配送渠道各自为政，而要接入全球标准则意味着一次又一次地重新集成。
每家承运商使用各自的状态码和字段名。接入方需要为每一次集成编写定制的映射。
你自己的司机、第三方车队和面单承运商各自以不同的结构上报跟踪信息，因此不存在一条统一的时间线。
要与基于 GS1 EPCIS、IATA ONE Record 或 UN/CEFACT 的合作伙伴共享跟踪信息，意味着要为每一个标准构建并维护单独的导出。
OTEP 是事件溯源的：事件时间线是事实来源，当前状态只是最新的那个事件。每个事件都围绕四个维度构建——What、When、Where 和 Why——这正是 EPCIS、ONE Record 和 UN/CEFACT 所共享的维度，因此这些标准只是简单的投影，而非并行的模型。对于只暴露当前状态（没有历史）的数据源，则通过为每次变化合成一个事件来处理，因此缺少事件列表绝不会成为阻碍。
自配送、第三方配送和承运商运单合并为每个跟踪号一条有序的事件时间线。
一套规范化的生命周期标准状态码和阶段，从每个数据源映射而来——不再需要针对每家承运商去猜测。
只需一个请求参数，即可将任意时间线投影为 GS1 EPCIS 2.0、IATA ONE Record 或 UN/CEFACT。
一个带有领域配置（domain profile）的通用协议——今天是包裹，接下来是搬家、外卖和仓储——共用一条事件主干。
一份公开、带版本的规范，任何人都可以实现。稳定的标识符、已发布的状态分类法和一个状态机。
通过一个全新的公开 API 与现有 API 并存对外提供。你已经集成的任何东西都不会改变。
公开、只读，位于现有的 /api/v1 前缀下。添加 ?format= 即可获得外部标准投影。
一条时间线进，四种表示出——由 ?format= 或 Accept profile 选择。
原生 OTEP 时间线（默认）。
GS1 EPCIS 2.0 ObjectEvents（JSON-LD）。
IATA ONE Record LogisticsEvents（JSON-LD）。
UN/CEFACT 运输状态事件。
OpenTelemetry OTLP 跟踪——把整个旅程作为一条 trace，每个事件作为一个 span。
兼容 AfterShip 的跟踪对象，带检查点（checkpoints）。
Shopify FulfillmentEvent 列表。
Amazon Shipping（SP-API）跟踪事件历史。
Walmart Marketplace 订单行状态与跟踪（粗粒度）。
BigCommerce 订单状态与跟踪（粗粒度）。
Magento 订单状态与跟踪（粗粒度）。
WooCommerce 订单状态与跟踪（粗粒度）。
Etsy 收据状态与跟踪（粗粒度）。
OGC SensorThings 观测数据（IoT）。
每个事件都映射到一个被归入各阶段的标准状态——从发货前，经过取件、运输和派送中，直到终态（delivered、returned、rejected 或 cancelled）。
OTEP 以开放规范的形式发布——由 Superroute 发起并维护，任何人都可以免费实现。它不是私有格式：事件信封、阶段主干、状态词汇和状态机就是公开、规范性的协议。
协议（信封、词汇、状态机、标准映射）是规范性的。某个实现者对其自身内部系统的绑定是信息性的，可以各有不同。
语义化版本。新增状态码或 profile 是向后兼容的；一个已发布标识符的含义永不改变。协议版本随每个事件一同传递。
状态码以 otep:<profile>:<code> 寻址，阶段以 otep:phase:<name> 寻址，因此词汇在各实现者之间保持全局无歧义。
一份任何一方都可采纳的公开规范，配有开放许可和公开的扩展流程——提议新的 profile 和状态码，而不是各自分叉。
生产者和消费者只需针对协议集成一次，而不是每家承运商集成一次。四个步骤即可获得一个符合规范的实现。
为每个事件发出其主体（What）、发生与记录时间（When）、地点（Where）以及一个标准状态加上可选原因（Why）。除了主体、时间和状态之外的每个字段都是可选的——有什么就填什么。
将你的原始状态码翻译为 OTEP 状态码和阶段。只暴露当前状态的数据源，为每次变化合成一个事件。
按发生时间对事件排序，容忍乱序到达，并将 delivered / returned / rejected / cancelled 视为终态。在注册前用 x- 前缀标记实验性状态码。
读取原生 OTEP，或请求 EPCIS / ONE Record / UN-CEFACT 投影——同一个事件，一个参数。一个新的输出标准只是一个新的序列化器。
Level 1——发出通用状态码、阶段和有效的状态转换。
Level 2——额外发出特定于 profile 的状态码以及至少一种外部标准投影。
OTEP 的四个维度与主流全球标准逐字段对齐，因此每个标准都成为一种输出投影，而非一次并行集成。
每个 OTEP 事件成为一个 ObjectEvent；状态映射到 CBV bizStep + disposition；地点映射到 readPoint。稳定的标准 URN。
每个事件成为一个带 eventCode 和 eventTimeType 的 LogisticsEvent；时间线挂接到一个 Shipment / Piece。
每个事件成为一个 TransportEvent，在一个 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 值是稳定的标准 URN。ONE Record 和 UN/CEFACT 的码值是针对最后一公里的最佳匹配，在对外使用前应对照官方代码表进行校验。
OTEP 的设计就是为了不断吸收各种标准。以下是互操作性路线图上的内容。
评估中: 其他市场平台（TikTok Shop、Temu、Shein 等）正在评估之中，待其公开履约 API 稳定后即会加入。
即使你出于任何原因无法直接使用 OTEP 标准，我们也热忱欢迎你与我们各退一步、相向而行——并且很乐意在互操作层面展开协作。
otep_status 字段——在你自己现有字段旁边，再返回一个规范化、与承运商无关的状态。它纯属增量，不会影响你当前的接入方。构建和验证一个符合 OTEP 规范的集成所需的一切——离线规范、机器可读的 schema 和码表、一个在线一致性校验器、一份 MCP 配置以及一个开发技能。
在浏览器中阅读完整的规范性协议文档。
在线查看在线浏览每个状态码、阶段与映射。
在线查看可直接复制粘贴的集成示例。
在线查看POST 一条时间线以检查其一致性；返回确切的错误和警告。
POSThttps://api.superlabel.ca/api/v1/otep/validate