NDC API Versions: How One Standard Leads to Endless Interpretations

While IATA officially defines NDC as a “data communication standard,” you’d be hard-pressed to find something more implementation-dependent than the NDC messaging schema. Today, 13 different NDC API versions coexist on IATA’s list of supported releases. Add the creative interpretations by airlines and technology providers, and standard starts to feel less like a rulebook and more like a loose guideline.

We engaged industry experts to trace the evolution of the NDC API from 17.2 to 24.1 and beyond, explain why divergence keeps happening, and examine what “NDC-compliant” actually means in practice — spoiler: not the same thing for everyone.

NDC schema evolution: what really changed and why it matters

It’s been more than a decade since 2012, when the International Air Transport Association introduced its New Distribution Capability (NDC) initiative to modernize airline retailing. Remember that year? Uber was beginning its global expansion, Airbnb was rapidly scaling into a mainstream hospitality platform, and cloud computing was becoming the new foundation of enterprise IT. The API economy was accelerating, while traditional airlines were still largely dependent on text-based legacy protocol EDIFACT — a situation that, to be fair, hasn’t changed dramatically so far.

Three years later, in 2015, IATA presented the first version of the new data exchange standard, followed by the launch of the official certification program in 2016. It sent a clear signal to the industry: NDC was here to stay. Still, the newborn schema was very much in its infancy, with many growing pains and improvements ahead.

Let’s see how that evolution unfolded across the official working versions.

17.2  — Setting the first milestone

When version 17.2 was released in 2017, NDC stopped being an experiment and started looking like a usable retailing framework. “If you look back in history, there were versions 15.2 and 16.2, but they were not focused on offer and order structure,” explains Praveen Kumar, Co-Founder and CTO at TPConnects, a global travel aggregation and distribution technology company.  “17.2 aligned key factors of offers and orders, and solidified the entire reshopping and servicing workflows.”

At the heart of 17.2 was a defined separation of retailing steps:

• AirShopping — search and initial offer display.
• OfferPrice — reprice and validate selected offers, and
• OrderCreate — confirm and create the booking.

The OfferPrice step was particularly important: airlines could reassess what a passenger had selected so far, apply pricing rules, validate availability, and continue upselling — all before moving to order creation. In practice, this functioned as a structured “shopping basket” layer within the NDC flow.

Another critical refinement was the clearer handling of A-La-Carte Offers — optional, unbundled services such as extra baggage or meals that can be purchased alongside a base fare. Earlier implementations often suffered from heavy shopping payloads when ancillaries were embedded directly into responses. By breaking add-ons into modular components, 17.2 facilitated their distribution while reducing message size.

Seat handling also improved significantly. Instead of including seat maps within large shopping responses, seat data was delivered through dedicated SeatAvailability messages. This architectural shift reduced performance bottlenecks and enabled per-seat pricing and dynamic seat upselling — a commercially meaningful enhancement for carriers.

Servicing also received a serious upgrade. The introduction of OrderReshop messages redesigned how post-booking changes were handled. Airlines could now:

• add ancillaries after booking,
• process cancellations,
• handle refunds, and
• simulate the financial impact of changes before confirming them.

That last capability was particularly critical. It allowed customers — or resellers — to preview the outcome of a change before committing, bringing airline servicing closer to modern eCommerce standards.

“17.2 actually addressed the bulk of airlines’ business needs,” says  Juan Pablo (JP) Olmos, Director of Channels and Distribution Consulting at Branchspace, a travel consultancy and tech provider working with airlines. “This version is associated a lot with Accelya; it shot Accelya to the top and really got them scaled, positioning them as a market leader in the NDC provider space. They got several customers among the pioneers of what we now know as modern airline retailing.”

Major carriers such as Lufthansa, British Airways, United, and American Airlines emerged as early NDC adopters — and many of them are still running on 17.2 today. It remains the most popular NDC version: 97 out of 184 airlines, sellers, and system providers participating in IATA’s Airline Retailing Maturity (ARM) program operate (at least, partially) on 17.2. Why change what works?

To sum up, version 17.2 did not deliver full Offer & Order retailing. But it made airline-controlled merchandising operational — and that is precisely why it became, and to a large extent remains, the industry’s first widely adopted NDC baseline.

18.x  — aligning with industry data model

Rather than introducing dramatic new retailing features, versions 18.x reorganised the message schema to align more closely with the Airline Industry Data Model (AIDM) — IATA’s shared blueprint for structuring aviation data.

As JP from Branchspace explains: “This moved NDC further away from random API logic toward a structure capable of supporting distribution in alignment with the AIDM. It signalled long-term robustness and scalability — which is why major technology providers such as Sabre and Amadeus began building around 18.x.”

Notably, version 18.2 was the first to introduce Order Creation without Tickets and EMDs. The capability allows airlines and agencies to manage flight sales through a single commercial record, replacing the traditional trio of e-ticket, Electronic Miscellaneous Document (EMD), and Passenger Name Record (PNR). This marked an important conceptual step toward IATA’s ONE Order vision — gradually moving the industry away from document-based architecture toward a unified, order-centric model.

Although the ONE Order concept promises reduced complexity, improved transparency, and more flexible retailing, it demands deep structural transformation across distribution systems, accounting processes, revenue management, and interline settlement. As a result, the transition is expected to take years — requiring coordinated change across airlines, technology providers, and sellers.

19.x  — refining the commercial and payment framework

If 18.x strengthened the structural backbone of NDC, 19.x — and especially 19.2 — focused on refining how airlines could retail, restrict, and settle offers in a more operationally robust way.

One of the important additions of 19.2 was the Service Taxonomy — a hierarchical code set designed to normalize how ancillary services are defined and described across the ecosystem. Instead of each airline structuring services differently, sellers and retailers could rely on a common classification logic, improving comparability and automation.

Another major enhancement was the introduction of machine-readable Offer Restrictions. Cancel and change conditions were no longer confined to free-text fare rules but could be transmitted in structured form — including change type, applicable fees, and effective or expiration date-times. This significantly improved automated repricing, post-booking servicing, and corporate travel policy validation.

The 19.x series also strengthened payment functionality, an area where earlier NDC versions faced practical limitations. Previously, NDC transactions relied on BSP/ARC Cash (payments settled via IATA Billing and Settlement Plan or Airline Reporting Corporation) and credit cards. Starting with 19.2, the schema introduced the Pay Using Payment Gateway capability, allowing travelers to be redirected to an airline’s website to complete payment using any method supported by the carrier, including digital wallets.

The inclusion of 3D Secure v2 was particularly significant. As airlines expanded API-based distribution beyond traditional GDS flows, they needed more robust fraud controls — especially in Europe, where customer verification became mandatory for many online payments. 3D Secure v2 enabled enhanced verification while supporting seamless biometric and mobile-based payments.

Another notable — though largely unrealized — feature introduced in 19.2 was the Ability to Indicate Masked Prices. This allows an airline to generate an order that preserves the original base amount while hiding it from the traveler when the seller applies a markup and acts as the merchant of record.

In such scenarios — for example, when distributing bulk fares — the airline can prevent travelers from seeing the underlying net price if they later retrieve their booking directly from the carrier. Although the capability exists technically, its adoption remains limited and largely depends on the commercial agreements between airlines and intermediaries.

In essence, the 19.x strengthened the commercial, servicing, and payment mechanics of NDC — making the standard more operationally viable for real-world retailing.

20.x — Extending NDC into accounting

Version 20.1 added support for IATA EasyPay, a prepaid e-wallet for travel agencies. More broadly, the 20.x family extended NDC to cover settlement and reconciliation processes. Praveen Kumar from TPConnects highlights that it’s where “the ONE Order scheme is really materialized since IATA brought it beyond retailing to accounting and service delivery.”

With 20.1, IATA introduced financial reporting messages tied directly to Orders. For the first time within the NDC framework, airlines and sellers could exchange standardized data about cleared payments, transferred funds, and settlement balances for defined financial periods. The schema also allowed previously reported payment clearances to be reversed when a transaction is voided, refunded, or corrected.

Version 20.2 expanded the financial layer by adding structured support for clearing — the step where obligations are reconciled and prepared for final settlement. It also launched event-based notifications so counterparties can be alerted when clearing actions occur.

These changes aimed to increase transparency between airlines and sellers around areas historically handled through external players such as the IATA BSP, ARC, or proprietary accounting platforms.

It’s worth noting that, despite critical refinements, versions 19.x and 20.x remain among the least popular NDC releases, with only 24 and 15 ARM participants implementing them, respectively. The industry was clearly waiting for the next major step forward before committing to wider adoption.

21.x — Establishing a new, backward-compatible baseline

The most important upgrade in the 21.x series wasn’t a flashy new retail feature — it was structural. With the introduction of shared Common Types, IATA consolidated data elements that had previously been defined separately across Offers and Orders. Instead of duplicating core structures such as amounts, identifiers, and associations in multiple places, the schema eventually defined them once and reused them across messages. It was a behind-the-scenes change, but a critical one: cleaner architecture, fewer inconsistencies, and a stronger foundation for future releases.

One of the key additions in 21.1 was the OrderQuote messages, which allow sellers to obtain a priced quote for a modified order before committing the change. They extend the OrderReshop functionality introduced in earlier versions by separating pricing from shopping. In practice, this brings post-booking servicing closer to modern eCommerce logic: first show the financial impact, then confirm the transaction.

Beyond that, the 21.x releases made it easier to identify which party plays which role in a distribution chain— whether airline, aggregator, or seller.

Version 21.3 soon became known as the new baseline, prompting many players to migrate. What made it so significant? “First, the servicing workflows became much more standardized,” explains Mahesh from Verteil. “Another major improvement was the more mature use of taxonomy, which enabled far more comprehensive support for ancillary sales.”

“NDC 21.3 provided the flow guidance for end-to-end retailing in the Offer and Order model, ” expands on the role of standardization Deepak Puthiyedath, Principal of Technology Solutions at NuFlights, an NDC-based distribution platform. “What we hope is that every airline adopts it. If that happens, it will become much easier for sellers to implement NDC.”

Besides, 21.3 rolled out something the NDC ecosystem had long struggled with — backward compatibility. For the first time, newer implementations could still understand and work with older message structures, reducing the need for disruptive migrations as the standard evolved.

The release also extended the framework beyond single-airline retailing by incorporating dedicated messages for interline scenarios — where multiple carriers participate in the same journey.

What started to happen with 21.3 on the formal side was version fragmentation. “Instead of a single release, we saw multiple iterations — 21.3.1, 21.3.2, and so on,” JP Olmos explains. “By the time the working groups reached 21.3.6, it had evolved enough that it no longer felt like a minor update within the 21.3 cycle. That’s when the decision was made to move forward under a new version generation — 24.1”.

24.x — Going further to full Offers and Orders

NDC 24.1 and later releases continue the transition toward the full Offers and Orders architecture. Key improvements include:

• better alignment between order items and payments, ensuring that each component — whether a flight segment or an ancillary service — is correctly linked to its financial record;
• more detailed handling of penalties and non-refundable components during reshops and cancellations, helping airlines maintain accurate accounting when itineraries change; and
• support for retaining the residual value of unused services within the order, allowing that value to be applied to future transactions instead of requiring an immediate refund.

Together, the above-mentioned enhancements addressed one of the biggest pain points in airline retailing: understanding price splits. As Mahesh from Verteil describes it: “What customers owe to an airline and what an airline owes to customers? In earlier versions, transparency was missing, particularly in exchange workflows. Why? Because the information was descriptive or human-oriented. But 24.1 made it machine-readable and very clear for end systems.”

Another key development is the growing role of digital identity in airline retailing. The 24.x version family aligns with IATA’s One ID initiative, which promotes the use of digital credentials across the end-to-end journey instead of requiring travelers to present documents at every touchpoint.

The same identity framework spans the entire distribution chain, where verifiable credentials allow both travelers and distribution partners — including airlines, retailers, and aggregators — to cryptographically prove who they are and validate the authenticity of the data they exchange. By enabling trusted interactions between participants, these mechanisms help reduce fraud and strengthen confidence across the airline retailing ecosystem.

“24.x is сalled a next-gen NDC, and for a reason,” Praveen from TPConnects sums up. “It finally brings the pieces together: offers and orders, disruption handling, servicing, settlement, and delivery — all in one coherent package.”

25.x and beyond: polishing the fundamentals

The latest NDC update refines the protocol by removing redundant messages, adding new code values for richer data, and improving baggage and airport messaging. It also enhances contactless travel support and deprecates outdated credential formats for better efficiency and interoperability.

A notable addition is the functionality enabling the communication of Tax IDs for passengers or payers in Latin America. This ensures compliance with regional tax regulations, improves the accuracy of tax data processing, and enhances the protocol’s relevance in key markets.

The focus on regional specifics is likely to continue in future releases.  “There’s been a lot of work done over the years by industry groups moderated by IATA,” says JP from Branchspace. “The fundamentals are largely covered, and the key use cases are documented. Now it’s more about drilling into market-specific requirements — things like local payment rules or tax reporting.”

Migration to a newer schema: what's slowing airlines down?

While each release introduces refinements, most airlines still rely on the 17.2 and 18.x workhorse versions, with no signs of a massive transition to the later schemas. Experts point to three main reasons for this.

Perceived value often falls short of the transition cost. IATA releases updates at least twice a year, introducing new functionality that is not equally relevant to every airline. At the same time, a full migration from one version to the next can take a large carrier between one and two and a half years — including the transition of partners. It’s therefore little surprise that airlines tend to wait until a change becomes truly mission-critical and offers clear operational or commercial benefits before committing to the transition.

“Early adopters have already spent significant time and money implementing features for end-to-end servicing — including splitting and updating PNRs. Now they’re being asked to go further,”  describes the situation Deepak Puthiyedath: “There are clear advantages, but carriers are realizing that implementing the NDC approach — and fully leveraging 21.3 — requires additional effort.”

So simply switching from one API to another is not enough — the entire infrastructure needs to be modernized to reap the benefits.

Old contracts and legacy tech limit how far airlines can take advantage of NDC. “Many of the improvements in booking flows matter little if carriers cannot fully use what NDC enables — such as richer ancillary sales or differentiated content across channels,” says Mahesh Pai, Product Director at Verteil, a Direct Connect airline distribution platform.

In practice, however, this flexibility is constrained by existing commercial agreements. “NDC was introduced on top of a legacy ecosystem, where airlines must maintain long-term contracts with distribution and technology partners,” Mahesh explains.

Long-term contracts with passenger service system (PSS) providers, often lasting 10 to 15 years, limit how quickly airlines can modernize their retailing capabilities. Legacy PSS platforms were built around static fare structures and were never designed to support dynamic pricing, bundling, personalized offers, and other aspects of modern commerce.

Even when airlines invest in more flexible pricing engines and order management layers on top of legacy PSS platforms, another set of restrictions remains. Full-content agreements with GDSs require carriers to offer the same products across channels in exchange for lower distribution fees — leaving little room for the product differentiation that NDC is meant to enable.

So if airlines are not yet using even the core capabilities of the current NDC version, the obvious question arises: why rush to the next one — at least until the broader infrastructure is ready to support it?

Key resellers may slow down migration. There’s another part of the equation: travel agencies that have built direct connections to specific airlines and invested heavily in a particular NDC version. “The first question the airline is going to get is: What’s in it for me?” says JP from Branchspace. “I’ve already spent all that time and resources to consume your content the way you told me. And now I must put more resources into doing the same thing. What’s the reason for this?”

If a carrier is not as large and influential as Lufthansa or British Airways, persuading travel agencies to invest in another round of development, testing, troubleshooting, and re-certification can be difficult.

At the same time, industry partners can also drive migration  — not necessarily prevent it. “When aggregators and large TMCs start asking, ‘Why are you still on version 17? Why not move to 21.3, which offers more benefits?’ That pressure eventually pushes airlines to upgrade,” Praveen from TPConnects shares.

It’s worth noting that starting with version 21.3, migration is expected to become less painful. “Most of the changes involve adding new features without disrupting the existing customer base,” Deepak Puthiyedath explains.

It’s not only a version: Why NDC is far from standard

The sheer number of NDC schema versions makes the question of what “NDC-compliant” actually means surprisingly difficult to answer. Airlines, aggregators, and travel sellers often talk about NDC adoption as if it were a single, uniform capability. In reality, the standard exists not only in multiple versions simultaneously — its implementation also varies from airline to airline.

“NDC schemas are very flexible,” notes Deepak Puthiyedath. “They don’t force airlines to implement things in a specific way.”

As a result, the same release can behave very differently depending on how a carrier deploys it.

Unique schema interpretation

A substantial gap exists between the IATA NDC standard and how individual airlines actually implement it. As a result, compliance often becomes theoretical rather than operational.

“At times, it feels as though IATA’s vision is being broadcast into a vacuum; the standard exists in principle, but the industry isn’t yet aligned on its execution,” says Jorge Díaz, Founder & CEO at AirGateway, an NDC content aggregator.

For many in the industry, the conversation still revolves around versioning. But Díaz argues this misses the real issue. “For me, versioning is one of the least relevant problems,” he explains. “What actually matters are workflows and how data exchanges are designed. Some airlines implement their own ‘exotic’ workflows that simply don’t match the standard — or the rest of carriers. That’s where homogenization becomes conceptually impossible for aggregators like us.”

For example, in one airline implementation, branded fares are not surfaced at the initial shopping stage. Instead, they are only available through a separate service list request — a step typically intended for ancillaries — where bundles are effectively hidden.

In a clean NDC flow, the first shopping response should present the core product upfront: itinerary options combined with fare families (Basic, Standard, Flex), along with clear pricing and rules. When this structure breaks, shopping becomes guesswork — the traveler selects a base option first, only to later discover that the actual range of choices was tucked away in a different part of the flow.

Backporting

Rather than fully migrating to the next NDC schema, many airlines take a hybrid approach — bolting selected features from newer releases onto existing booking flows. “It’s a cheaper, simpler way to capture the business value of new releases without taking on the massive hurdle of a full transition,” explains JP at Branchspace. “From an industry perspective, it’s not ideal — but for individual airlines it’s a pragmatic approach, and it’s really hard to change that behavior.”

According to Praveen Kumar from TPConnects, “upgrading to a new version is not just a technical exercise.”  Airlines operate within complex technology ecosystems, with many integrated platforms still relying on business logic built around earlier APIs. That’s why carriers adopt partial migrations, “with shopping and booking running on 21.3  or 24.1 while servicing remains on, for example, 17.2.” In such cases, an order management system (OMS) acts as an intermediary, coordinating data exchange between different API versions.

Uneven automation

When resellers don’t connect to airlines directly and instead access NDC through a middleware layer (GDS or aggregator), many of the underlying technical headaches stay out of sight. Normalizing messy airline implementations is exactly what these platforms do, so agencies rarely worry about which NDC version sits behind the curtain. What they care about is simple: does the connection support the capabilities they need?

Imagine one airline supporting the full booking and servicing journey; Another covering only fragments. The result is a familiar frustration for agencies: an operation works with Carrier A and fails with Carrier B — even though both market themselves as “NDC-enabled.”

Is true standardization possible?

Will the multi-layered problem of NDC inconsistencies be solved anytime soon? Probably not — if anything, it may deepen. “I think that IATA should have been much more strict and selective when designing their airline NDC certification process, which is the only tool the industry has to empower the delivery of actual standard NDC deployments.” Jorge from AirGateway notes. “But of course, this would be only my main recommendation.” As more vendors enter the market, new interpretations and variations are likely to emerge, adding further complexity for aggregators, GDSs, and other distribution players.

Deepak Puthiyedath, on the other hand, notes that starting with version 21.3, IATA certification timelines have increased, as the organization has begun applying stricter guardrails: “They’re slowly putting controls in place to make sure the flows are implemented correctly and that messages include all mandatory attributes.”

But it doesn’t mean carriers necessarily delay their launch until IATA approval. “If certification takes too long, airlines that have already invested in building their NDC capabilities may be reluctant to hold back — and then potentially spend more fixing gaps,” Deepak says.

Why interlining in NDC doesn’t work as expected

One area where NDC still feels in its diapers is interlining. The reason is simple: it goes far beyond airline retailing, which was the standard’s original focus. Selling seats operated by a partner carrier means supporting not only shopping and booking but also the complex commercial and operational relationships between airlines.

“There are a lot of things involved — rate parity, settlement, contractual rules. None of this was standardized until NDC 20.2 introduced the meta-agreement, which later evolved into the seller–retailer agreement in 21.3,” explains Praveen Kumar from TPConnects.

From a technical perspective, interlining in the Offers and Orders world works very differently from the traditional GDS-driven EDIFACT model. Instead of routing messages through a central system, airlines must establish direct connections and call each other’s APIs.

This approach allows carriers to move away from the traditional proration-based model, where ticket revenue is divided among partner airlines after the sale. Instead, according to Mahesh Pai from Verteil, carriers will be able to “get live offers from partners and give passengers what really matters, based on the customer and trip context.”

Rebuilding four decades of legacy processes, however, takes time. Despite the complexity ahead, Praveen sees steady progress: “There’s a lot happening these days — many workshops are taking place, and I’m personally involved in several of them at IATA.”

JP from Branchspace is somewhat less optimistic. “IATA has tried many times to build consensus on how interlining should work with Offers and Orders. But it’s not something you solve quickly. We’re starting to see some efforts move beyond pilots, yet the pace is nowhere near the scale of mainstream NDC evolution. I expect specific airline partnership efforts to push the standards forward and help solidify what should be the detailed norm for modern interlining.”

What’s next?

Where will the schema and the entire NDC initiative move next?

According to Praveen Kumar, the next phase of NDC evolution will focus less on specific message schemas and more on the broader offer-order-settle-delivery model: “The real question is how much personalization an offer can bring for each seller or frequent flyer, and how much additional value ancillaries can generate through dynamic bundling and price optimization.”

The turning point, he argues, is the shift from static, filed fares to dynamically generated offers, with the resulting order communicated across the ecosystem — from travel sellers to operational software such as departure control and accounting platforms. “That’s where the entire industry is moving.”

Mahesh from Verteil confirms this: “So far, NDC has largely been viewed as a distribution mechanism. But alongside it, IATA has been driving the One Order initiative, which is where much of the real innovation in airline retailing is happening. Going forward, the evolution of NDC will be less about new schemas or version numbers and more about how the industry supports retail-driven airline operations.”