IATA ONE Record: choose the first air-cargo data exchange to implement

Choose an exchange that removes a specific handoff dispute

A forwarder and a handling agent agree that four pieces were received, but one receipt timestamp conflicts with the handover evidence. The forwarder needs to challenge that observation without overwriting the handler’s record or exposing unrelated commercial data.

A useful first ONE Record exchange would let those two partners inspect the expected pieces and receipt observations, then resolve a disputed event through its responsible owner. The objective is a bounded handoff: share the agreed receipt evidence and process corrections with explicit permissions.

The IATA — ONE Record describes a data-sharing standard using a common data model, standardised APIs and security mechanisms. Implementing it requires an agreement between the participating organisations. It does not mean every air-cargo partner can immediately exchange every record.

Define the first use case before defining the whole data model

Write a short exchange agreement. Name the forwarder, handler, station, booking family and responsible operational contacts. Limit the first exchange to the records needed for receipt reconciliation.

The agreement should specify who creates each piece identity, who reports receipt and condition observations, and who can correct an erroneous event. Identify how partner references map to the same business object without discarding their original values.

Decide which timestamps describe the physical event, when the source recorded it and when the other party received it. Those distinctions help explain a late update without rewriting history. Agree the meaning of “received,” “held” and “eligible for the next step.” Do not import those labels from one screen without checking their operational scope.

Keep rates, margins and unrelated customer information outside the exchange unless there is an explicit need and authorisation. A data object can contain more information than the receiving party needs for this use case.

Confirm versions and semantics together

The IATA — ONE Record API specification identifies API version 2.3.0 as endorsed on 25 July 2026 and specifies cargo ontology 3.2.0 or later for that API version. That is a checked specification reference, not a statement about either partner's installed system.

Record the actual API and data-model versions offered by both participants. Check compatible object structures, required identifiers, code values, authentication, authorisation and error responses. If one partner supports a different version, resolve the compatibility question before treating a successful connection as a working business exchange.

A technically valid record can still be operationally misleading. For example, a receipt timestamp without station context may refer to the forwarder's warehouse rather than the agreed handler. The acceptance test therefore needs both schema validation and a person checking that the event answers the intended question.

Worked example: correct an observation without taking ownership of it

The following exchange is illustrative. A forwarder owns booking B-73 and the expected identities of four pieces, P1–P4. The handler owns the receipt observations for those pieces at station H. All four have been received; this example concerns the quality and control of the shared record.

For P3, the handler's record states receipt at 08:10 IST on 15 October. The forwarder has handover evidence showing 09:10 and submits a correction request with that evidence. While the request is pending, the handler's existing observation remains visible alongside the dispute. The receiving application must not silently present the proposed time as an accepted correction.

After reviewing the evidence, the handler's authorised owner accepts 09:10 as the corrected receipt time. Preserve the original observation, the request, the decision and the resulting current value. The sixty-minute change corrects a recorded time; it does not establish an operational delay or a commercial liability.

The same exchange should keep the forwarder's buy and sell rates inaccessible to the handler. Correctly sharing four piece identities does not justify exposing every field reachable from their parent booking.

This example establishes neither cargo release nor flight loading. It demonstrates who may see a record, who may challenge it and who can approve its correction.

Compare a shared view, an adapter and a wider platform change

A partner-facing view can answer the receipt question quickly if both parties already trust one system's operational records. It may be sufficient for a limited relationship, although it offers less portability than a shared standard.

An adapter can translate the existing operational records into the agreed ONE Record objects and process permitted partner interactions. Its success depends on faithful mapping and maintained ownership rules. Adding an adapter does not repair missing piece identifiers in the source system.

A wider platform replacement may be justified by several business needs, but this first exchange alone does not establish that case. Compare its cost and disruption with the bounded adapter or existing partner capability.

Use the same disputed-observation scenario in each assessment. Ask the provider to demonstrate the pending request, owner decision, retained history and restricted partner view. A complete-looking shipment record is insufficient if a correction can bypass its owner.

Exercise permissions at the object and relationship level

Access should follow the partner's agreed role and business relationship. Test the permitted piece records, their linked shipment information and any documents reachable through those links. A restricted field is not protected if it can be recovered through a related object or export.

Use an illustrative set of twelve access tests: eight permitted operational reads, two attempts to read restricted commercial fields and two requests for unrelated booking records. The expected outcomes are eight successful reads and four refusals, with no restricted values returned. Passing these cases verifies only the tested boundary, not the security of the entire implementation.

Distinguish a request to change data from an accepted change. A receiving system should not display a proposed correction as authoritative before the required owner has acted. Retain the request, decision and resulting version so the partners can resolve disagreements.

Observe usefulness as well as message success

Evaluate the proportion of expected pieces that can be reconciled at the review cutoff, the number of unresolved identity mappings and the age of missing or disputed events. Count unique pieces and business changes, not message deliveries.

Have the forwarder's coordinator and handler's supervisor independently answer the same operational questions from the exchanged records. Differences reveal a semantic or workflow gap even if every API request succeeded.

Also test a temporary connection failure. Show the last received event time, keep outstanding updates visible and reconcile the restored exchange against the source. A stale shared view should not appear current merely because the application remains accessible.

Start with an agreement that can be demonstrated

The first useful ONE Record exchange is a small operational agreement implemented consistently by two partners. Its value comes from reliable meaning, accountable ownership and appropriate access, rather than the number of fields shared.

Next actions

1. Select one partner and receipt-reconciliation question with a named operational owner on each side.
2. Confirm supported versions, piece identities, event meanings and permitted fields.
3. Demonstrate the disputed observation, owner-approved correction and twelve access cases using approved test data.
4. Review unresolved discrepancies before extending the exchange to more partners or decisions.

A focused assessment should begin with the partner's actual capabilities and a recent disputed handoff. Those inputs show whether the main obstacle is identity, semantics, permissions or implementation.