Un protocolo de eventos abierto y neutral respecto al proveedor para operaciones de seguimiento, entrega, cumplimiento y logística. Desde transportistas y mensajeros hasta almacenes, casilleros, rutas y futuras redes de movilidad, OTEP ofrece un lenguaje común para cada evento operativo.
OTEP (Open Tracking Event Protocol) es un protocolo abierto y neutral respecto al proveedor para el ciclo de vida de cualquier sujeto rastreable. Iniciado y administrado por Superroute, es libre de implementar por cualquiera. Unifica la entrega propia, la entrega de terceros, el seguimiento de transportistas, la prueba de entrega, las excepciones, los escaneos en nodos y la trayectoria del conductor en un solo flujo de eventos con un único vocabulario de estados, y está diseñado para extenderse a mudanzas, entrega de comida, almacenamiento y más.
El seguimiento está fragmentado. Cada transportista nombra los campos de forma distinta, cada canal de entrega vive en su propio silo, y conectarse a estándares globales implica reintegrar una y otra vez.
Cada transportista usa sus propios códigos de estado y nombres de campo. Los consumidores escriben mapeos a medida para cada integración.
Tus propios conductores, las flotas de terceros y los transportistas de etiquetas reportan el seguimiento con una forma distinta cada uno, por lo que no existe una única línea de tiempo.
Compartir el seguimiento con socios en GS1 EPCIS, IATA ONE Record o UN/CEFACT implica construir y mantener una exportación independiente para cada uno.
OTEP se basa en eventos: la línea de tiempo de eventos es la fuente de verdad y el estado actual es solo el último evento. Cada evento se modela en torno a cuatro dimensiones — Qué, Cuándo, Dónde y Por qué — las mismas dimensiones compartidas por EPCIS, ONE Record y UN/CEFACT, de modo que esos estándares se convierten en simples proyecciones en lugar de modelos paralelos. Las fuentes que solo exponen un estado actual (sin historial) se gestionan sintetizando un evento por cada cambio, así que la falta de una lista de eventos nunca es un bloqueo.
La entrega propia, la entrega de terceros y los envíos de transportistas se fusionan en una sola línea de tiempo de eventos ordenada por número de seguimiento.
Un ciclo de vida normalizado de códigos de estado y fases canónicos, mapeado desde cada fuente — se acabaron las conjeturas por transportista.
Proyecta cualquier línea de tiempo a GS1 EPCIS 2.0, IATA ONE Record o UN/CEFACT con un solo parámetro de la solicitud.
Un protocolo general con perfiles de dominio — paquetería hoy; mudanzas, entrega de comida y almacenamiento después — sobre una columna vertebral de eventos compartida.
Una especificación pública y versionada que cualquiera puede implementar. Identificadores estables, una taxonomía de estados publicada y una máquina de estados.
Expuesto a través de una nueva API pública junto a la existente. Nada de lo que ya integras cambia.
Públicos, de solo lectura, bajo el prefijo existente /api/v1. Añade ?format= para una proyección a un estándar externo.
Una línea de tiempo de entrada, cuatro representaciones de salida — elegidas mediante ?format= o un perfil Accept.
Línea de tiempo OTEP nativa (predeterminada).
GS1 EPCIS 2.0 Eventos de objeto ( JSON-LD ).
IATA ONE Registrar eventos logísticos ( JSON-LD ).
Eventos de estado de transporte UN/CEFACT.
Trazas OpenTelemetry OTLP — el trayecto como una traza, cada evento un span.
Objeto de seguimiento compatible con AfterShip con puntos de control.
Lista de Shopify FulfillmentEvent.
Historial de eventos de seguimiento de Amazon Shipping (SP-API).
Estado y seguimiento de líneas de pedido de Walmart Marketplace (aproximado).
Estado de pedido y seguimiento de BigCommerce (aproximado).
Estado de pedido y seguimiento de Magento (aproximado).
Estado de pedido y seguimiento de WooCommerce (aproximado).
Estado de recibo y seguimiento de Etsy (aproximado).
Observaciones de OGC SensorThings (IoT).
Cada evento se mapea a un estado canónico agrupado en fases — desde el pre-envío pasando por la recogida, el tránsito y el reparto hasta un estado terminal (entregado, devuelto, rechazado o cancelado).
OTEP se publica como una especificación abierta — iniciada y administrada por Superroute, libre de implementar por cualquiera. No es un formato privado: el sobre de eventos, la columna de fases, el vocabulario de estados y la máquina de estados son el protocolo público y normativo.
El protocolo (sobre, vocabulario, máquina de estados, mapeos estándar) es normativo. Los enlaces de un implementador con sus propios sistemas internos son informativos y pueden diferir.
Versionado semántico. Añadir códigos o perfiles es compatible hacia atrás; el significado de un identificador publicado nunca cambia. La versión del protocolo viaja con cada evento.
Los códigos se direccionan como otep:<profile>:<code> y las fases como otep:phase:<name>, de modo que el vocabulario se mantiene globalmente inequívoco entre implementadores.
Una especificación pública que cualquier parte puede adoptar, con una licencia abierta y un proceso de extensión público — propón nuevos perfiles y códigos en lugar de bifurcar.
Los productores y consumidores se integran una vez contra el protocolo, no una vez por transportista. Cuatro pasos para una implementación conforme.
Emite cada evento con su sujeto (Qué), el instante de ocurrencia y de registro (Cuándo), la ubicación (Dónde) y un estado canónico más una razón opcional (Por qué). Todos los campos excepto sujeto, tiempo y estado son opcionales — completa lo que tengas.
Traduce tus códigos de estado en bruto a códigos de estado y fases de OTEP. Las fuentes que solo exponen un estado actual sintetizan un evento por cada cambio.
Ordena los eventos por su instante de ocurrencia, tolera la llegada fuera de orden y trata delivered / returned / rejected / cancelled como terminales. Marca los códigos experimentales con un prefijo x- hasta que se registren.
Lee OTEP nativo, o solicita una proyección EPCIS / ONE Record / UN-CEFACT — el mismo evento, un parámetro. Un nuevo estándar de salida es solo un nuevo serializador.
Nivel 1 — emite los códigos universales, las fases y las transiciones de estado válidas.
Nivel 2 — además emite códigos específicos del perfil y al menos una proyección a un estándar externo.
Las cuatro dimensiones de OTEP se alinean campo a campo con los principales estándares globales, de modo que cada uno se convierte en una proyección de salida en lugar de una integración paralela.
Cada evento OTEP se convierte en un ObjectEvent; el estado se mapea a CBV bizStep + disposition; la ubicación a readPoint. URNs estándar estables.
Cada evento se convierte en un LogisticsEvent con un eventCode y un eventTimeType; la línea de tiempo se adjunta a un Shipment / Piece.
Cada evento se convierte en un TransportEvent con un código de estado de transporte bajo un 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 |
Los valores CBV de EPCIS son URNs estándar estables. Los valores de código de ONE Record y UN/CEFACT son la mejor aproximación para la última milla y deben validarse contra las listas de códigos oficiales antes de su uso externo.
OTEP está construido para seguir absorbiendo estándares. Estos están en la hoja de ruta de interoperabilidad.
En evaluación: Otros marketplaces (TikTok Shop, Temu, Shein y más) se están evaluando y se añadirán a medida que sus APIs públicas de cumplimiento se estabilicen.
Incluso si no puedes usar el estándar OTEP directamente, por cualquier motivo, te damos la cálida bienvenida a encontrarnos a mitad de camino — y nos alegra colaborar a nivel de interoperabilidad.
otep_status a las respuestas de tu API y a los valores de retorno — un único estado normalizado e independiente del transportista junto a tus propios campos existentes. Es puramente aditivo y no afectará a tus consumidores actuales.Todo lo que necesitas para construir y verificar una integración conforme con OTEP — la especificación sin conexión, un esquema y un libro de códigos legibles por máquina, un validador de conformidad en vivo, una configuración MCP y una habilidad de desarrollo.
Lee la especificación normativa completa del protocolo en tu navegador.
Ver en líneaExplora en línea cada código de estado, fase y mapeo.
Ver en líneaEjemplos de integración listos para copiar y pegar.
Ver en líneaEnvía una línea de tiempo por POST para comprobar si es conforme; recibe los errores y advertencias exactos.
POSThttps://api.superlabel.ca/api/v1/otep/validate
La especificación normativa completa del protocolo, sin conexión.
Descargar .mdPDF listo para imprimir de la especificación del protocolo.
Descargar .pdfValida tus cargas útiles contra el esquema de la línea de tiempo de OTEP.
Descargar .jsonLos códigos de estado, fases, puentes y mapeos externos completos y precisos — generados a partir de la implementación.
Descargar .jsonConecta un asistente de IA a las herramientas de OTEP para un desarrollo asistido.
Descargar .jsonUna habilidad lista para usar que guía la creación de código conforme con OTEP.
Descargar .mdLos endpoints de OTEP están activos bajo /api/v1/otep. Explóralos en la referencia de la API REST.
Abrir referencia de la API