Cut IATA ONE Record Rollout Risk: Eight Steps for Logistics Teams

ONE Record is IATA’s single-record standard that turns every shipment into a machine-readable digital twin, replacing scattered messages with one shared source of truth. For logistics teams, that means real-time, event-driven visibility instead of chasing status updates by phone or email. Getting there means adopting a common data model, a REST API, a security specification, and the legal framework that lets partners actually share the data.

TL;DR:

• Most industry stakeholders are aware of ONE Record, but fewer have the necessary infrastructure or partner agreements in place to implement it effectively.
• Adopting ONE Record requires mapping existing shipment data to a JSON-LD based ontology and establishing secure API connections before running pilots.
• Pilots have demonstrated successful use cases like automated eAWB updates, booking pre-advice, and real-time customs status sharing, though partner onboarding remains a key bottleneck.
• Main barriers to rollout include legal review delays, legacy system mapping efforts, and uneven vendor support for ONE Record integration.
• Utilizing a TMS that supports native API, ACL, and event-driven workflows, like FreightSuite, can greatly streamline the technical and operational integration process.

Table of Contents

• What ONE Record is: the three pillars behind the standard
• Why ONE Record matters: the operational payoff
• How ONE Record works technically: the mechanics integration teams must plan for
• A step-by-step path from evaluation to production
• What industry pilots have already proven
• Readiness, risk, and the barriers still slowing rollout
• How a modern TMS maps to ONE Record’s requirements
• How FreightSuite fits into a ONE Record rollout
• Sources
• FAQ

What ONE Record is: the three pillars behind the standard

ONE Record replaces the old world of fragmented EDI messages with a single logical construct: the virtual shipment record. Instead of dozens of separate messages describing pieces of a shipment’s journey, every party works from the same digital object, updated in place and visible to whoever has permission to see it.

That object is built from Logistics Objects, the standard’s basic unit of data. A Logistics Object might represent a shipment, a piece, a booking, or a waybill, and each one carries a unique identifier so any system can reference it precisely. IATA structures these objects using an ontology, a shared vocabulary that defines what a “shipment” or “piece” means in a way every participant interprets the same way. The technical format for expressing that ontology is JSON-LD, a data format that lets systems attach meaning to fields rather than passing raw, ambiguous text strings.

Three components make the standard work together in practice.

• Data model: a JSON-LD ontology that defines Logistics Objects and how they relate to one another, so a shipment record means the same thing to an airline, a forwarder, and a ground handler.
• API: a RESTful interface that lets systems create, read, update, and subscribe to Logistics Objects using standard HTTP methods.
• Security specification: a framework for authentication and access control that determines who can see or modify a given record.

Together these pillars let a shipment’s data live in one place while still being visible, in real time, to every party with a legitimate need to see it. That is a structural departure from message-based EDI, where each update travels as a separate, disconnected transmission.

Why ONE Record matters: the operational payoff

The technical shift behind ONE Record produces a business result logistics leaders actually care about: fewer exceptions and less manual work. Because updates flow through a shared record rather than a chain of messages, a status change appears once and propagates to every subscribed party automatically. That event-driven model closes the gap between “something changed” and “everyone downstream knows about it.”

The reduction in manual reconciliation compounds across a shipment’s life cycle. A single accurate record means fewer discrepancies between what an airline’s system shows and what a forwarder’s TMS displays, and fewer staff hours spent calling partners to confirm a status that should have updated itself.

More than 70% of surveyed industry stakeholders reported awareness of ONE Record, while readiness sat closer to 50%, according to IATA’s 2025 industry survey. That gap between awareness and readiness is the story of where the industry stands right now: most people know what ONE Record is, fewer have the infrastructure or partner agreements in place to run it.

Practical use cases already point at where the near-term value sits.

• Automated eAWB updates remove the need for a separate message every time a waybill status changes.
• Booking pre-advice lets a forwarder see a confirmed booking the moment an airline records it, not after a follow-up message.
• Piece-level tracking gives visibility down to the individual piece rather than the shipment as a whole.
• Customs status updates propagate automatically to every party watching a shipment’s clearance progress.

Respondents to that same survey asked for more pilots, more peer examples, and continued IATA support, which tells you the gap is less about belief in the standard and more about a shortage of proven playbooks to follow.

How ONE Record works technically: the mechanics integration teams must plan for

Adopting ONE Record is a mapping exercise before it is a coding exercise. Every field your TMS currently tracks (shipment number, piece count, weight, status codes) has to be reconciled against the standard Onerecord, which defines Logistics Objects like Shipment, Piece, Booking, and Waybill along with their properties. Where your internal field names diverge from the ontology’s terms, that mapping becomes the foundation every later API call depends on.

Once the mapping is settled, four technical mechanics govern how systems actually talk to each other.

1. HTTP operations. A system publishes a new Logistics Object with a POST request, retrieves one with GET, and submits a change request with PATCH, with every change logged to an audit trail.
2. Publish and subscribe. Rather than polling for updates, a subscribing system registers a callback URL and receives event notifications when a Logistics Object it cares about changes, with retry logic handling delivery failures.
3. Access control lists. Every Logistics Object carries an ACL that determines which companies or systems can read or write to it, and permissions can be granted or revoked per partner.
4. Hosting and audit trails. Because ONE Record assumes decentralized hosting, each party runs its own server holding its own data, and every read, write, or permission change is logged for accountability.

That last point trips up more implementation teams than any other. ONE Record does not centralize data in an IATA-run repository. Each company hosts its own Logistics Objects and grants access explicitly, which means access is denied by default until a partner is added to an ACL, according to the IATA Implementation Playbook. Security guidance from IATA’s white paper on securing the digital future of air cargo frames this as a deliberate design choice: data sovereignty stays with the party that created the record, and every access grant is traceable.

For a team used to point-to-point EDI messaging, this is the mental shift that matters most. You are not building one integration to one partner. You are provisioning a server that can serve, authenticate, and audit requests from any partner you choose to grant access to, governed by a chain of trust rather than a fixed set of bilateral connections.

A step-by-step path from evaluation to production

Moving from “we should look at ONE Record” to a working pilot follows a sequence that IATA’s own playbook lays out, with four workstreams running in parallel rather than one after another.

1. Sign the Multilateral Data Agreement. Executing the IATA MDA is the legal step that lets you share data with any other signatory without negotiating a separate bilateral NDA for each partner, and it should involve your legal and privacy teams from day one.
2. Choose a hosting model. Decide whether you will run your own server or use a vendor-hosted environment, and confirm it can serve JSON-LD payloads, enforce ACLs, and maintain an audit trail.
3. Build authentication and access control. Implement the authorization layer that checks every incoming request against your ACLs before granting read or write access to a Logistics Object.
4. Map your TMS fields to the ontology. Translate your existing shipment, booking, and piece data into the standard Logistics Object structure before building any endpoints.
5. Build or connect API endpoints. Implement the POST, GET, and PATCH operations your systems need, and test them against a partner’s sandbox environment before going live.
6. Test the pub/sub flow. Confirm that subscription callbacks fire reliably, that retries work when a delivery fails, and that your audit trail captures every change correctly.
7. Pilot with one or two partners. Pick a single high-value use case, such as eAWB automation or customs status updates, run it with a small number of partners, and define clear KPIs before expanding.
8. Train, monitor, and iterate. Run internal training so operations staff understand what changed, monitor the pilot against your KPIs, and expand scope only once the first use case is proven.

Pro Tip: Start with a single use case and a single partner. A narrow, well-monitored pilot exposes ACL and pub/sub problems faster than a broad rollout ever will.

Each step should produce a concrete artifact: a signed MDA, a hosting decision document, a field mapping spreadsheet, a tested API contract, and a KPI dashboard. Skipping the documentation step is the single most common reason pilots stall when they try to scale past their first partner, because nobody wrote down what the mapping or the access rules actually were.

What industry pilots have already proven

IATA’s ONE Record fact sheet lists participation from companies including Cathay Pacific, CHAMP, Turkish Cargo, and Schenker, spanning use cases from electronic air waybill automation to piece-level tracking and customs status integration. Most of these remain pilot-stage rather than full production, which matches where the broader industry sits: real technical proof points exist, but scaled, everyday use across a carrier’s entire network is still the exception rather than the norm.

• eAWB automation has moved furthest, since it builds on an already digitized document and mostly needs the ONE Record layer added on top.
• Booking pre-advice pilots show forwarders receiving confirmed booking data without a separate message, cutting a manual check out of the process.
• Customs status updates and TMS-to-airline tracking pilots demonstrate the pub/sub model working across organizational boundaries, though partner onboarding remains the slowest part of each rollout.

The consistent lesson across these pilots is that the technology is rarely the blocker. Partner onboarding, agreeing who owns which data, and settling access permissions before the first API call takes longer than writing the integration code itself.

Readiness, risk, and the barriers still slowing rollout

The gap between awareness and readiness in IATA’s 2025 survey traces back to a consistent set of blockers. Legal teams often stall on the MDA before technical teams even start. Legacy systems built around EDI messaging require real mapping effort before they can speak the ONE Record ontology. Partners on the other side of a planned integration are frequently not ready themselves, and vendor support for ONE Record connectors is still uneven across the TMS market.

• Sign the MDA early, since legal review timelines often run longer than the technical build itself.
• Run scoped pilots rather than attempting a network-wide rollout on the first try.
• Prioritize high-value use cases like eAWB automation, where the data is already digitized and the integration effort is lowest.
• Reuse IATA’s own resources, including the playbook and technical specification, rather than rebuilding mapping guidance from scratch.

Once a pilot is live, the KPIs that prove value are straightforward to track: fewer manual status-check touches per shipment, a higher share of shipments with accurate on-time status, and fewer customs exceptions caught late. Those three numbers tell you faster than any survey whether the integration is paying off.

How a modern TMS maps to ONE Record’s requirements

A TMS built to support ONE Record needs to act as both a publisher and a subscriber. When a shipment status changes inside the system, that update needs to trigger a POST or PATCH request against the relevant Logistics Object, with the change logged to an audit trail automatically rather than as an afterthought.

• JSON-LD payload support so the TMS can read and write Logistics Objects in the ontology’s native format.
• API connectors that handle authentication, ACL checks, and the POST, GET, and PATCH operations without custom code for every partner.
• Event orchestration and workflows that trigger internal actions (a customs alert, a booking confirmation) automatically when a subscribed Logistics Object changes.
• Audit logging that satisfies the traceability requirement built into the security specification.

A TMS that handles these natively removes a meaningful chunk of the integration work described earlier in this piece, since the mapping, connector, and workflow layers arrive already built rather than needing custom development for every new partner.

How FreightSuite fits into a ONE Record rollout

Freight forwarders evaluating ONE Record face a choice: build the API layer, ACL management, and workflow orchestration in-house, or run it on a TMS that already has that plumbing in place. FreightSuite is built as an alternative to legacy systems, with automation and AI agent orchestration built natively rather than bolted on through add-ons.

• Air freight tracking and automation built into FreightSuite’s air freight management system, relevant to the tracking and pre-advice use cases described above.
• Native workflow automation that can trigger the internal actions a ONE Record event should cause, without a separate integration project.
• Rate management, finance, and operations running in the same platform, so a ONE Record integration does not sit disconnected from the rest of your data.

If you are planning a pilot, start by reviewing FreightSuite’s product capabilities and asking about ONE Record connectors and migration support during a demo.

FAQ

What is IATA ONE Record in simple terms?

ONE Record is IATA’s standard for sharing shipment data through a single digital record instead of separate messages. It uses a common data model, a REST API, and a security specification so every partner works from the same up-to-date shipment information.

What is the IATA Multilateral Data Agreement?

The MDA is the legal agreement that lets companies share ONE Record data with any other signatory without negotiating a separate bilateral contract for each partner. Signing it, as described in IATA’s Implementation Playbook, is typically the first step in a rollout, alongside internal legal review.

Where is IATA headquartered?

IATA’s headquarters are in Montreal, Canada, according to IATA’s own program pages.

What does the IATA code stand for?

IATA stands for the International Air Transport Association, the trade body that develops standards including ONE Record for the air transport industry.

How does a TMS support ONE Record integration?

A TMS supports ONE Record by publishing and subscribing to Logistics Objects through the standard’s API, using JSON-LD payloads and enforcing access control lists. FreightSuite builds this kind of automation and workflow orchestration natively into its air freight management system, reducing the custom integration work a forwarder would otherwise need to build.