Um protocolo de eventos aberto e neutro em relação a fornecedores para operações de rastreamento, entrega, fulfillment e logística. De transportadoras e estafetas a armazéns, cacifos, rotas e futuras redes de mobilidade, o OTEP fornece uma linguagem comum para todos os eventos operacionais.
O OTEP (Open Tracking Event Protocol) é um protocolo aberto e neutro em relação a fornecedores para o ciclo de vida de qualquer objeto rastreável. Iniciado e mantido pela Superroute, é gratuito para qualquer pessoa implementar. Unifica a entrega própria, a entrega por terceiros, o rastreamento de transportadoras, a prova de entrega, as exceções, as leituras em nós e a trajetória do motorista num único fluxo de eventos com um único vocabulário de estados — e foi concebido para se estender a mudanças, entrega de comida, armazenamento e muito mais.
O rastreamento está fragmentado. Cada transportadora nomeia os campos de forma diferente, cada canal de entrega vive no seu próprio silo, e ligar-se a padrões globais significa reintegrar uma e outra vez.
Cada transportadora usa os seus próprios códigos de estado e nomes de campos. Os consumidores escrevem mapeamentos à medida para cada integração.
Os seus próprios motoristas, as frotas de terceiros e as transportadoras de etiquetas reportam cada um o rastreamento num formato diferente, pelo que não existe uma única cronologia.
Partilhar o rastreamento com parceiros em GS1 EPCIS, IATA ONE Record ou UN/CEFACT significa construir e manter uma exportação separada para cada um.
O OTEP é baseado em eventos: a cronologia de eventos é a fonte da verdade e o estado atual é apenas o evento mais recente. Cada evento é estruturado em torno de quatro dimensões — O Quê, Quando, Onde e Porquê — as mesmas dimensões partilhadas por EPCIS, ONE Record e UN/CEFACT, pelo que esses padrões se tornam simples projeções em vez de modelos paralelos. As fontes que expõem apenas um estado atual (sem histórico) são tratadas sintetizando um evento por cada mudança, para que uma lista de eventos em falta nunca seja um obstáculo.
A entrega própria, a entrega por terceiros e os envios por transportadora fundem-se numa única cronologia de eventos ordenada por número de rastreamento.
Um ciclo de vida normalizado de códigos de estado canónicos e fases, mapeado a partir de cada fonte — sem mais suposições por transportadora.
Projete qualquer cronologia para GS1 EPCIS 2.0, IATA ONE Record ou UN/CEFACT com um único parâmetro de pedido.
Um protocolo geral com perfis de domínio — encomendas hoje; mudanças, entrega de comida e armazenamento a seguir — sobre uma espinha de eventos partilhada.
Uma especificação pública e versionada que qualquer pessoa pode implementar. Identificadores estáveis, uma taxonomia de estados publicada e uma máquina de estados.
Exposto através de uma nova API pública, a par da existente. Nada com que já se integra é alterado.
Públicos, só de leitura, sob o prefixo /api/v1 existente. Adicione ?format= para uma projeção num padrão externo.
Uma cronologia à entrada, quatro representações à saída — escolhidas por ?format= ou por um perfil Accept.
Cronologia OTEP nativa (predefinição).
GS1 EPCIS 2.0 ObjectEvents ( JSON-LD ).
IATA ONE Registrar eventos logísticos ( JSON-LD ).
Eventos de estado de transporte UN/CEFACT.
Rastreios OpenTelemetry OTLP — a jornada como um rastreio, cada evento um span.
Objeto de rastreamento compatível com AfterShip com pontos de verificação.
Lista Shopify FulfillmentEvent.
Histórico de eventos de rastreamento Amazon Shipping (SP-API).
Estado e rastreamento de linha de encomenda Walmart Marketplace (aproximado).
Estado e rastreamento de encomenda BigCommerce (aproximado).
Estado e rastreamento de encomenda Magento (aproximado).
Estado e rastreamento de encomenda WooCommerce (aproximado).
Estado de receção e rastreamento Etsy (aproximado).
Observações OGC SensorThings (IoT).
Cada evento mapeia para um estado canónico agrupado em fases — desde o pré-envio, passando pela recolha, trânsito e saída para entrega, até a um estado terminal (entregue, devolvido, recusado ou cancelado).
O OTEP é publicado como uma especificação aberta — iniciada e mantida pela Superroute, gratuita para qualquer pessoa implementar. Não é um formato privado: o envelope de evento, a espinha de fases, o vocabulário de estados e a máquina de estados são o protocolo público e normativo.
O protocolo (envelope, vocabulário, máquina de estados, mapeamentos padrão) é normativo. As ligações de um implementador aos seus próprios sistemas internos são informativas e podem diferir.
Versionamento semântico. Adicionar códigos ou perfis é retrocompatível; o significado de um identificador publicado nunca muda. A versão do protocolo viaja com cada evento.
Os códigos são endereçados como otep:<profile>:<code> e as fases como otep:phase:<name>, para que o vocabulário se mantenha globalmente inequívoco entre implementadores.
Uma especificação pública que qualquer parte pode adotar, com uma licença aberta e um processo de extensão público — proponha novos perfis e códigos em vez de fazer um fork.
Os produtores e consumidores integram-se uma vez com o protocolo, não uma vez por transportadora. Quatro passos para uma implementação conforme.
Emita cada evento com o seu objeto (O Quê), a hora de ocorrência e de registo (Quando), a localização (Onde) e um estado canónico mais um motivo opcional (Porquê). Todos os campos exceto objeto, hora e estado são opcionais — preencha o que tiver.
Traduza os seus códigos de estado em bruto para códigos de estado e fases OTEP. As fontes que expõem apenas um estado atual sintetizam um evento por cada mudança.
Ordene os eventos pela hora de ocorrência, tolere chegadas fora de ordem e trate entregue / devolvido / recusado / cancelado como terminais. Marque os códigos experimentais com um prefixo x- até serem registados.
Leia OTEP nativo, ou solicite uma projeção EPCIS / ONE Record / UN-CEFACT — o mesmo evento, um parâmetro. Um novo padrão de saída é apenas um novo serializador.
Nível 1 — emita os códigos universais, as fases e as transições de estado válidas.
Nível 2 — emita adicionalmente códigos específicos de perfil e pelo menos uma projeção num padrão externo.
As quatro dimensões do OTEP alinham-se campo a campo com os principais padrões globais, pelo que cada um se torna uma projeção de saída em vez de uma integração paralela.
Cada evento OTEP torna-se um ObjectEvent; o estado mapeia para CBV bizStep + disposition; a localização para readPoint. URNs padrão estáveis.
Cada evento torna-se um LogisticsEvent com um eventCode e eventTimeType; a cronologia liga-se a um Shipment / Piece.
Cada evento torna-se um TransportEvent com um código de estado de transporte sob um 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 |
Os valores CBV do EPCIS são URNs padrão estáveis. Os valores de código ONE Record e UN/CEFACT são a melhor correspondência para a última milha e devem ser validados em relação às listas de códigos oficiais antes do uso externo.
O OTEP foi construído para continuar a absorver padrões. Estes estão no roteiro de interoperabilidade.
Em avaliação: Outros marketplaces (TikTok Shop, Temu, Shein, e mais) estão a ser avaliados e serão adicionados à medida que as suas APIs públicas de fulfillment estabilizem.
Mesmo que não possa usar o padrão OTEP diretamente, por qualquer motivo, recebemo-lo de braços abertos para nos encontrarmos a meio caminho — e teremos todo o gosto em colaborar ao nível da interoperabilidade.
otep_status às respostas e valores de retorno da sua API — um único estado normalizado e independente da transportadora, a par dos seus próprios campos existentes. É puramente aditivo e não afetará os seus consumidores atuais.Tudo o que precisa para construir e verificar uma integração conforme com o OTEP — especificação offline, esquema e codebook legíveis por máquina, um validador de conformidade ao vivo, uma configuração MCP e uma skill de desenvolvimento.
Leia a especificação normativa completa do protocolo no navegador.
Ver onlineExplore online cada código de estado, fase e mapeamento.
Ver onlineExemplos de integração prontos para copiar e colar.
Ver onlineEnvie (POST) uma cronologia para verificar se está conforme; receba de volta os erros e avisos exatos.
POSThttps://api.superlabel.ca/api/v1/otep/validate
A especificação normativa completa do protocolo, offline.
Transferir .mdPDF pronto a imprimir da especificação do protocolo.
Transferir .pdfValide os seus payloads em relação ao esquema da cronologia OTEP.
Transferir .jsonOs códigos de estado, fases, pontes e mapeamentos externos completos e exatos — gerados a partir da implementação.
Transferir .jsonLigue um assistente de IA às ferramentas OTEP para desenvolvimento assistido.
Transferir .jsonUma skill pronta a usar que orienta a construção de código conforme com o OTEP.
Transferir .mdOs endpoints OTEP estão ativos em /api/v1/otep. Explore-os na referência da API REST.
Abrir Referência da API