ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

— May 16, 2026 · 9 min read

IATA ONE Record: the future of air cargo EDI

Air cargo has relied for fifty years on proprietary EDI messages — Cargo-IMP, then Cargo-XML. Since 2018 IATA has been developing a new standard, ONE Record, which breaks with message logic and adopts the linked-graph model. This article frames the shift, its timeline, and what it means for integrators.

From Cargo-IMP to Cargo-XML: fifty years of messages

The historical air cargo standard is called Cargo-IMP (Cargo Interchange Message Procedures), born in the 1970s, designed around line-structured messages (the famous FWB for cargo declaration, the FFM for flight manifest, the FHL for the house waybill list). The format is flat, tailored for SITA and X.25 links, and remains largely operational in cargo hubs in 2026. IATA published as early as 2010 an XML version — Cargo-XML — to modernise the exchanges without breaking semantics. Cargo-XML is now in version 4 (released in 2022), with roughly thirty messages covering shipper, forwarder, carrier, ground handler, and customs sides.

Cargo-IMP and Cargo-XML share the same model: a message is an atomic snapshot of an event (booking, manifest, status update), sent from one actor to another. If ten stakeholders are involved in a shipment (shipper, forwarder, origin hub, carrier, transit hub, destination hub, arrival forwarder, customs, consignee, and the final truck), each must rebuild its own local store from the messages received. The model is message-centric; the shared state lives nowhere.

ONE Record: the data-sharing rupture

ONE Record flips this paradigm. The founding idea, published in 2018 in IATA Cargo Services Conference Resolution 672, is that each transport actor publishes its data as a linked graph (JSON-LD), accessible to other authorised actors via an API. The standard rests on an ontological data model (Logistics Data Model) describing cargo concepts (Shipment, Waybill, Piece, TransportMovement, Booking, etc.) with their properties and relationships. Each actor hosts a Logistics Object server that exposes these objects via a REST API, and actors subscribe to state changes.

The most vivid analogy is that of a blockchain without a blockchain or of a shared Notion between actors: instead of sending copies of the object at every update, you share access to a canonical object that evolves over time. ONE Record change requests formalise the proposed updates, and each actor can audit the full chronology of a shipment.

Adoption timeline: pilots, transition, target

IATA launched a ONE Record Pilot with about twenty carriers between 2020 and 2023 (Air France-KLM, Cathay Pacific, Lufthansa Cargo, Qatar Airways Cargo, ANA, and others). The first operational productionisations cover targeted use cases: status notifications from hubs, sharing information with customs authorities (notably the experimentation with the European Commission via the eFTI project), sharing temperature and IoT sensor data for pharma freight.

The IATA resolution provides for a gradual transition: ONE Record and Cargo-XML coexist during migration, and IATA has not announced a hard cut-off date for retiring Cargo-XML messages. Effective deprecation will depend on the penetration of Logistics Object servers at forwarders and carriers, which must in practice reach a critical mass before legacy partners decide to switch.

What changes technically

For an air cargo EDI integrator, the switch is not just a format change: it is a change of operating model. Four major consequences:

  • From batch to event-driven. Where an FFM sent over SITA followed a per-flight cadence, an attribute change on a ONE Record Shipment generates an almost instantaneous webhook. Air cargo EDI processing architectures must pivot to an event reception and asynchronous reconciliation model.
  • Mutual authentication mandatory. Each call to a Logistics Object server goes through OAuth 2.0 with scopes, and each actor publishes its own API gateway. Credential management and token rotation discipline become daily operational skills.
  • Shared semantic reference. The Logistics Data Model is published as an OWL/JSON-LD ontology; developers can generate TypeScript or Python code from the schema, and translation between internal objects and ONE Record objects becomes testable end-to-end.
  • Native audit and chronology. Every modification to a Logistics Object is traced by construction; compliance with customs requirements (notably ICS2 in the EU since 2023, expansion 2024-2025) becomes a side effect of the model rather than a feature to add.

Conclusion: a patient but structural migration

ONE Record is probably the deepest transformation of the air cargo EDI landscape since the birth of Cargo-IMP. The rupture is not about format but about paradigm inversion: messages are no longer exchanged, access to canonical objects is shared. For vendors and integrators in 2026, the right reflex is to start a sandbox exploration with an open-source Logistics Object server (several implementations exist), identify one or two pilot partners, and map which Cargo-XML messages can be projected onto ONE Record equivalents.

To dig further, the modern integration architecture page gives the general framing this shift fits into, and the EDI/API convergence analysis details why an event-driven model over REST resources now coexists smoothly with historical EDI.