From PNR to Order: Integrating Airline Distribution Without Losing Your Mind

If you want to understand why travel integration is hard, look at what a single flight booking actually touches. A record format designed in the 1960s. A messaging standard from the 1980s. And a new XML-based API that some airlines support fully, some partially, and some not at all. All three, in one booking flow, at the same time.

We’ve spent years in this domain: Amadeus integrations, booking engines, the plumbing behind travel platforms. The thing outsiders underestimate is that none of these layers replaced the previous one. They stacked. The integration work is holding all three at once and hiding the seams from the traveler.

The GDS and the record that never dies

Start with the Global Distribution System, the B2B network that aggregates airline inventory and pushes it to agencies and online travel sites. Three companies dominate it: Amadeus, Sabre, and Travelport. Between them they carry the overwhelming majority of GDS air bookings.

At the heart of every booking sits the PNR, the Passenger Name Record. SABRE introduced it in the 1960s, IATA standardized the concept as Recommended Practice 1830, and it has stayed structurally consistent ever since. You know it as that six-character record locator on your boarding pass. Structurally it behaves like an append-only log living inside the system that created it: name, itinerary, seat, ticketing status, all accreted over time.

The PNR works. It has worked for sixty years. That’s exactly why it’s still here, and why any integration that touches airline content has to speak it fluently.

EDIFACT, still carrying the traffic

The messages that move bookings between systems largely run on EDIFACT, the UN-developed EDI standard from the 1980s, standardized as ISO 9735. It was designed for an era of slow, expensive bandwidth, so it’s terse, text-only, and efficiency-first to a fault. IATA’s PADIS message set, which airlines and airports use to exchange passenger data, is defined for EDIFACT.

If you’ve never parsed an EDIFACT message, picture a dense string of segments and delimiters that assumes you already own the specification and a decoder. It carries no rich content: no images, no branded-fare detail, none of the merchandising a modern airline wants to sell. It moves the essential facts and nothing more, which was the right trade in 1985 and is a constraint everyone’s been working around ever since.

An integration engineer in travel is, among other things, an EDIFACT translator. The format isn’t going away on any timeline that matters to your project, so you learn it, you build the adapter, and you own it.

NDC: the new layer that doesn’t cover everything

Then came IATA’s New Distribution Capability (NDC), the XML-based standard meant to fix EDIFACT’s poverty of content. Duffel frames the point exactly right: NDC exists because the old text-only format couldn’t carry the rich, merchandised offers airlines now want to sell. NDC lets the airline control the offer, bundle ancillaries, show branded fares, and present its product the way it wants rather than being flattened into legacy fields.

The reframing runs deeper than richer payloads. NDC pushes toward an Offer-and-Order model: Offers, which are airline-controlled and dynamically priced, and Orders, a single record spanning the customer lifecycle, meant to eventually replace the tangle of PNR, e-ticket, and EMD. Amadeus’s own developer split shows the transition mid-stride. Its Self-Service APIs are clean REST and JSON but explicitly can’t do ticketing, booking management, or NDC content; the heavier Enterprise APIs handle PNR create-and-modify, ticketing, and NDC-sourced content over REST and SOAP.

The catch is the whole reason this is hard. NDC didn’t replace anything. Adoption is partial and uneven: different airlines support different NDC schema versions, some support it deeply, some barely, some not at all. So now you’re not bridging two formats. You’re bridging three, plus version drift within NDC itself, plus the reconciliation between PNR-based legacy records and Order-based NDC records for the same trip.

What the integration actually does

Put it together and the job becomes clear. A traveler searches, and behind that search your system may be pulling availability from EDIFACT GDS feeds for some carriers and NDC APIs for others, each with its own shape, its own freshness, its own quirks. You normalize all of it into one internal representation so the traveler sees a single coherent list, not the fragmentation underneath.

Then they book, and you write to whichever backend owns that content (a PNR here, an NDC Order there) while presenting one consistent confirmation. When they change the trip, you route the modification to the right system in the right format. The traveler experiences one smooth flow. Underneath, you’re translating across sixty years of accumulated standards and hiding every seam.

There’s a caching tension running through all of it. Live availability polling against airline systems is expensive and rate-limited, so distributors cache fares and availability. That introduces staleness, and staleness produces the “that offer is no longer available” re-price failure at the worst possible moment, right as the traveler clicks buy. Managing that trade-off between fresh and fast is a core piece of the engineering, not a detail.

Why the old layers persist

It’s tempting to see EDIFACT and the PNR as legacy debt someone should have retired. That misreads why they’re still here. They carry mission-critical traffic reliably, an enormous installed base depends on them, and every airline and agency in the network would have to move together for them to go away. That coordination problem is why the transition to NDC and Offer-and-Order is measured in years, not quarters, with even leading carriers still building it out.

So the integration reality in travel isn’t “migrate off the old thing.” It’s “bridge the old thing and the new thing, correctly, in the same booking, for years.” The skill isn’t knowing NDC. It’s knowing NDC and EDIFACT and the PNR, understanding why each exists, and building the layer that makes them look like one system to the person just trying to book a flight.