What is NDC? A practical guide to IATA’s New Distribution Capability

NDC (New Distribution Capability) is a data standard created by IATA that lets airlines build offers dynamically and sell them directly to any seller through an API, instead of publishing fares in advance for a GDS to assemble. It moves airline distribution from a fares-and-tickets model to an offers-and-orders model, which is the bigger change hiding behind the acronym.

Why NDC exists

Traditional distribution was built around filed fares. An airline published fares and rules, a fare-filing system distributed them, and global distribution systems combined them with availability to produce a price. That model works well for a seat from A to B. It works poorly for anything an airline wants to sell beyond the seat: bundles, seat selection, bags, lounge access, personalised prices or content that differs by channel.

IATA introduced NDC so that airlines control the offer. The seller sends a request with context — who is travelling, where, sometimes which corporate agreement applies — and the airline responds with offers it built for that request.

Offers and orders in plain terms

An offer is a priced proposal the airline is willing to sell, valid for a limited time. It may include the flight, a fare brand, and optional services. An order is what exists once the customer accepts: a single record the airline owns that describes what was bought and its state.

That is different from the GDS world, where the passenger name record (PNR) holds the itinerary and separate electronic tickets and miscellaneous documents represent payment and entitlement. NDC keeps those documents underneath today, but the long-term direction is a single order record — the subject of IATA ONE Order.

The core NDC message flow

A typical booking moves through a small set of request/response pairs:

1. AirShopping — search for offers matching the trip.
2. OfferPrice — confirm the price and conditions of a chosen offer before payment.
3. ServiceList / SeatAvailability — fetch ancillaries and seat maps for that offer.
4. OrderCreate — accept the offer and create the order, usually with payment.
5. OrderRetrieve — read the current state of the order.
6. OrderChange / OrderCancel — service the order after booking.

Each airline implements a version of the schema and a subset of capabilities, so “supports NDC” never means the same thing twice. Integration work is mostly about those differences.

What actually changes for a travel platform

For engineers, NDC is not just a new connector. It changes several assumptions:

• Prices are dynamic and expire. Caching search results the way GDS-era platforms did leads to prices that cannot be booked. Store an expiry with every offer and re-price before payment. The trade-offs are covered in caching flight search.
• Servicing moves to the airline. Changes and refunds happen through the airline’s API against its order, not through a GDS terminal. Your platform needs per-airline capability flags.
• Content gets richer. Fare brands, images and service descriptions arrive with the offer, so the UI must render variable content without breaking.
• The booking record is the airline’s. Your system keeps its own order model, with the airline’s order ID as an external reference.

The cleanest way to absorb all of this is one internal offer and order model with thin channel adapters, an approach described in designing a booking engine for GDS and NDC.

Direct connect or aggregator?

There are three common ways to reach NDC content:

Route	Strengths	Trade-offs
Direct airline API	Full content, closest to the airline’s roadmap	One integration, contract and certification per airline
GDS as NDC aggregator	Familiar commercial model, many airlines through one pipe	Feature coverage depends on the aggregator’s implementation
Specialist NDC aggregator	Fast access to many airlines, normalised responses	Another dependency and commercial layer

Most platforms combine them: direct connections for the few carriers that matter most to their market, and an aggregator for the long tail.

Common integration pitfalls

• Assuming schema version means behaviour. Two airlines on the same NDC version can still return different structures for the same concept.
• Ignoring servicing until later. Booking is the easy part. Changes, involuntary schedule changes and refunds are where most operational cost hides.
• Treating errors as strings. Map each airline’s error codes to an internal vocabulary early, so support teams and customers see consistent messages.
• Weak observability. Log every call with a correlation ID, latency and outcome per airline and per message type.

The takeaway

NDC is best understood as a shift in who builds the product: the airline creates the offer, and the seller presents and services it. Platforms that model offers, expiry and order servicing explicitly — rather than bolting NDC onto a fare-based design — are the ones that can add airlines without rebuilding their core.