AeroToys
IATA NDC

IATA NDC, demystified.

NDC — the New Distribution Capability — is the XML standard that lets airlines distribute richer, contextual offers through indirect channels without going through the GDS line-item model. It is necessary, it is not sufficient, and it is widely misunderstood. Here's the unfiltered version.

What NDC is

NDC is a set of XML message schemas defined by IATA. The headline messages cover:

  • AirShoppingRQ/RS — request and response for offers, including bundled ancillaries and rich content.
  • OfferPriceRQ/RS — repricing a selected offer.
  • OrderCreateRQ/RS — creating an Order from an offer.
  • OrderRetrieveRQ/RS, OrderChangeRQ/RS, OrderCancelRQ/RS — servicing the Order.
  • ServicingRQ/RS, ItinReshopRQ/RS, SeatAvailabilityRQ/RS, and a long tail of more specialised messages.

NDC schemas evolve. The major release lines (17.2, 19.2, 21.3, and more recent) introduce non-trivial breaking changes; production deployments routinely pin to a specific version per partner.

What NDC is not

  • Not a runtime. NDC defines messages, not the offer engine that produces them, the order store that holds them, or the rules engine that decides which offer to return.
  • Not a replacement for the PSS by itself. An NDC façade in front of a legacy PSS is still a legacy PSS. Real NDC value comes from a real Offer engine behind it.
  • Not the whole MAR story. NDC is the distribution layer. ONE Order, Dynamic Offer Construction, and the Offer/Order operating model are equally important.
  • Not necessarily channel-neutral. Many NDC implementations only run for agency channels; the airline's own dot-com may still be on a separate path. Aligning channels is a separate, hard project.

How NDC pairs with ONE Order

NDC and ONE Order are designed to work together: NDC is the conversation, ONE Order is the record. An OrderCreateRQ from a seller produces a ONE Order record on the airline side. Subsequent servicing (OrderChangeRQ, voluntary/involuntary changes, refunds) operates on that single record rather than orchestrating PNR + e-ticket + EMD writes.

In practice, almost every airline runs a hybrid for years — NDC orders alongside legacy PNR/ticket flows. The translation layer is where most of the operational pain sits.

Where AeroToys sits in an NDC stack

  • Open Shopping Engine handles the OD search → offer assembly that backs AirShoppingRS.
  • Offer Management applies pricing, bundling, and personalisation rules through RuleForge.
  • Order Management persists the resulting Order in DocumentForge as an append-only record.
  • Open Tax Engine (community) supplies the canonical tax ruleset every step uses.
  • Open Schedules Data backs the schedule and OD graph queries.

The NDC gateway itself — the actual XML message handling — is a thin layer on top of these. We're intentional that NDC schema versioning lives at the edge, not deep in the engine.

FAQs

Do I need NDC before I do ONE Order?
No. They're independent decisions. You can deploy ONE Order on direct channels first, where you control both ends, and bring NDC online later for indirect distribution. Many carriers do exactly this.
Which NDC version should we target?
Target the version your largest indirect partners are on, then expect to support 2–3 versions concurrently for years. Plan the version-translation layer up front; it's not a small thing.
Does AeroToys ship a certified NDC gateway?
Not yet — that's planned alongside the Offer & Order suite. Today we provide the engines underneath an NDC gateway. The first community-hosted reference NDC gateway is on the roadmap.