Un protocole d'événements ouvert et neutre vis-à-vis des fournisseurs, dédié au suivi, à la livraison, au traitement des commandes et aux opérations logistiques. Des transporteurs et coursiers aux entrepôts, casiers, tournées et futurs réseaux de mobilité, OTEP offre un langage commun pour chaque événement opérationnel.
OTEP (Open Tracking Event Protocol) est un protocole ouvert et neutre vis-à-vis des fournisseurs, dédié au cycle de vie de tout sujet traçable. Initié et géré par Superroute, il est libre d'implémentation pour quiconque. Il unifie la livraison en propre, la livraison par des tiers, le suivi transporteur, la preuve de livraison, les exceptions, les scans de nœuds et la trajectoire des chauffeurs en un seul flux d'événements doté d'un vocabulaire de statuts unique — et il est conçu pour s'étendre au déménagement, à la livraison de repas, au stockage et au-delà.
Le suivi est fragmenté. Chaque transporteur nomme ses champs différemment, chaque canal de livraison vit dans son propre silo, et se connecter aux standards mondiaux signifie réintégrer encore et encore.
Chaque transporteur utilise ses propres codes de statut et noms de champs. Les consommateurs écrivent un mappage sur mesure pour chaque intégration.
Vos propres chauffeurs, les flottes tierces et les transporteurs d'étiquettes signalent chacun le suivi sous une forme différente, si bien qu'aucune chronologie unique n'existe.
Partager le suivi avec des partenaires sur GS1 EPCIS, IATA ONE Record ou UN/CEFACT implique de construire et de maintenir un export distinct pour chacun.
OTEP est basé sur les événements (event-sourced) : la chronologie des événements est la source de vérité et le statut actuel n'est que le dernier événement. Chaque événement s'articule autour de quatre dimensions — Quoi, Quand, Où et Pourquoi — les mêmes dimensions partagées par EPCIS, ONE Record et UN/CEFACT, de sorte que ces standards deviennent de simples projections plutôt que des modèles parallèles. Les sources qui n'exposent qu'un statut actuel (sans historique) sont traitées en synthétisant un événement par changement, de sorte qu'une liste d'événements manquante ne constitue jamais un obstacle.
La livraison en propre, la livraison par des tiers et les expéditions transporteur fusionnent en une seule chronologie d'événements ordonnée par numéro de suivi.
Un cycle de vie normalisé de codes de statut et de phases canoniques, mappé depuis chaque source — fini les approximations propres à chaque transporteur.
Projetez n'importe quelle chronologie vers GS1 EPCIS 2.0, IATA ONE Record ou UN/CEFACT avec un seul paramètre de requête.
Un protocole général avec des profils de domaine — le colis aujourd'hui ; le déménagement, la livraison de repas et le stockage ensuite — sur une seule colonne vertébrale d'événements partagée.
Une spécification publique et versionnée que chacun peut implémenter. Identifiants stables, une taxonomie de statuts publiée et une machine à états.
Exposé via une nouvelle API publique aux côtés de l'existante. Rien de ce avec quoi vous intégrez déjà ne change.
Publics, en lecture seule, sous le préfixe existant /api/v1. Ajoutez ?format= pour une projection vers un standard externe.
Une chronologie en entrée, quatre représentations en sortie — choisies via ?format= ou un profil Accept.
Chronologie OTEP native (par défaut).
GS1 EPCIS 2.0 Événements d'objet ( JSON-LD ).
IATA ONE Enregistrer les événements logistiques ( JSON-LD ).
Événements de statut de transport UN/CEFACT.
Traces OpenTelemetry OTLP — le trajet comme une trace, chaque événement comme un span.
Objet de suivi compatible AfterShip avec points de contrôle.
Liste Shopify FulfillmentEvent.
Historique d'événements de suivi Amazon Shipping (SP-API).
Statut de ligne de commande et suivi Walmart Marketplace (grossier).
Statut de commande et suivi BigCommerce (grossier).
État de commande et suivi Magento (grossier).
Statut de commande et suivi WooCommerce (grossier).
Statut de reçu et suivi Etsy (grossier).
Observations OGC SensorThings (IoT).
Chaque événement correspond à un statut canonique regroupé en phases — de la pré-expédition jusqu'à un état terminal (livré, retourné, refusé ou annulé), en passant par la collecte, le transit et la sortie pour livraison.
OTEP est publié comme une spécification ouverte — initiée et gérée par Superroute, libre d'implémentation pour quiconque. Ce n'est pas un format privé : l'enveloppe d'événement, la colonne vertébrale des phases, le vocabulaire de statuts et la machine à états constituent le protocole public et normatif.
Le protocole (enveloppe, vocabulaire, machine à états, mappages standard) est normatif. Les liaisons d'un implémenteur vers ses propres systèmes internes sont informatives et peuvent différer.
Versionnement sémantique. Ajouter des codes ou des profils est rétrocompatible ; la signification d'un identifiant publié ne change jamais. La version du protocole voyage avec chaque événement.
Les codes sont adressés sous la forme otep:<profile>:<code> et les phases sous la forme otep:phase:<name>, afin que le vocabulaire reste globalement non ambigu entre implémenteurs.
Une spécification publique que toute partie peut adopter, avec une licence ouverte et un processus d'extension public — proposez de nouveaux profils et codes au lieu de forker.
Les producteurs et les consommateurs s'intègrent une seule fois contre le protocole, et non une fois par transporteur. Quatre étapes vers une implémentation conforme.
Émettez chaque événement avec son sujet (Quoi), son heure d'occurrence et d'enregistrement (Quand), son lieu (Où) et un statut canonique plus une raison facultative (Pourquoi). Chaque champ hormis le sujet, l'heure et le statut est facultatif — renseignez ce dont vous disposez.
Traduisez vos codes de statut bruts vers les codes de statut et phases OTEP. Les sources qui n'exposent qu'un statut actuel synthétisent un événement par changement.
Ordonnez les événements par heure d'occurrence, tolérez les arrivées dans le désordre, et traitez livré / retourné / refusé / annulé comme terminaux. Marquez les codes expérimentaux d'un préfixe x- jusqu'à leur enregistrement.
Lisez l'OTEP natif, ou demandez une projection EPCIS / ONE Record / UN-CEFACT — même événement, un seul paramètre. Un nouveau standard de sortie n'est qu'un nouveau sérialiseur.
Niveau 1 — émettre les codes universels, les phases et les transitions d'état valides.
Niveau 2 — émettre en plus les codes spécifiques au profil et au moins une projection vers un standard externe.
Les quatre dimensions d'OTEP s'alignent champ par champ avec les principaux standards mondiaux, si bien que chacun devient une projection de sortie plutôt qu'une intégration parallèle.
Chaque événement OTEP devient un ObjectEvent ; le statut correspond à bizStep + disposition CBV ; le lieu à readPoint. URNs standard stables.
Chaque événement devient un LogisticsEvent doté d'un eventCode et d'un eventTimeType ; la chronologie est rattachée à un Shipment / Piece.
Chaque événement devient un TransportEvent avec un code de statut de transport sous 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 |
Les valeurs CBV d'EPCIS sont des URNs standard stables. Les valeurs de code ONE Record et UN/CEFACT sont les plus adaptées au dernier kilomètre et doivent être validées par rapport aux listes de codes officielles avant tout usage externe.
OTEP est conçu pour continuer à absorber des standards. Ceux-ci figurent sur la feuille de route d'interopérabilité.
À l'étude: D'autres places de marché (TikTok Shop, Temu, Shein et d'autres) sont à l'étude et seront ajoutées à mesure que leurs API publiques de traitement des commandes se stabilisent.
Même si vous ne pouvez pas utiliser directement le standard OTEP, pour quelque raison que ce soit, nous vous invitons chaleureusement à faire un bout de chemin vers nous — et nous serons ravis de collaborer au niveau de l'interopérabilité.
otep_status à vos réponses d'API et à vos valeurs de retour — un seul statut normalisé et indépendant du transporteur, aux côtés de vos propres champs existants. C'est purement additif et n'affectera pas vos consommateurs actuels.Tout ce dont vous avez besoin pour construire et vérifier une intégration conforme à OTEP — spécification hors ligne, schéma et recueil de codes lisibles par machine, un validateur de conformité en direct, une configuration MCP et une compétence de développement.
Lisez la spécification normative complète du protocole dans votre navigateur.
Voir en ligneParcourez en ligne chaque code de statut, phase et correspondance.
Voir en ligneExemples d'intégration prêts à copier-coller.
Voir en ligneEnvoyez une chronologie en POST pour vérifier sa conformité ; recevez en retour les erreurs et avertissements exacts.
POSThttps://api.superlabel.ca/api/v1/otep/validate
La spécification normative complète du protocole, hors ligne.
Télécharger .mdPDF prêt à imprimer de la spécification du protocole.
Télécharger .pdfValidez vos charges utiles par rapport au schéma de chronologie OTEP.
Télécharger .jsonLes codes de statut, phases, passerelles et mappages externes complets et exacts — générés à partir de l'implémentation.
Télécharger .jsonConnectez un assistant IA aux outils OTEP pour un développement assisté.
Télécharger .jsonUne compétence prête à l'emploi qui guide la construction de code conforme à OTEP.
Télécharger .mdLes points de terminaison OTEP sont en service sous /api/v1/otep. Explorez-les dans la référence de l'API REST.
Ouvrir la référence de l'API