NDC API Integration

Skip key takeaways

Updated September 5, 2026

• Scope the message set, not "NDC" as one API AirShopping, OfferPrice, OrderCreate, OrderChange, OrderReshop and OrderChangeNotif are separate messages with separate implementation work.
• Direct connect moves the distribution-chain obligation onto you The last Distributor before the airline owns the chain data; an aggregator absorbs that, direct connect does not.
• Servicing lives inside OrderChange and OrderReshop There is no separate refund message and OrderChangeNotif needs a listener, not only a client.
• The ARM index is a capability review, not a certification IATA's registry explicitly disclaims endorsing any commercial product.
• ONE Order is a separate standard from NDC Implementing NDC messages does not by itself replace the PNR or e-ticket.

Copy takeaways

In short: NDC API integration means implementing an XML message set organized around Offer and Order rather than adding one booking endpoint to a fare system, and it is open to any implementer without IATA membership. The scoping questions that matter are which messages a build actually needs, whether to go through an aggregator or connect directly to the airline, and how servicing after the sale gets handled once a booking exists. This guide walks the message set, the aggregator-versus-direct tradeoff and the sequencing we use when a travel software team scopes a direct connect against existing GDS rails.

What NDC changes against GDS distribution

Most teams coming from a GDS background assume NDC is a newer, faster booking API bolted onto the same fare-and-PNR model they already know. It is not. According to IATA's own program page, "New Distribution Capability (NDC) is a data exchange format based on Offer and Order management processes for airlines to create and distribute relevant offers to the customer regardless of the distribution channel." That distinction, Offer and Order as the working objects rather than fare and PNR, is the first thing we correct in a scoping conversation, because it changes which messages a build has to implement and in what order they get called.

The wire format is XML, and the standard sits under an IATA-run program rather than a single airline's own specification, which matters for anyone building a platform that has to serve more than one carrier. Openness is the second correction we make: an agency, TMC or aggregator does not need IATA membership to implement against the standard, and non-IATA members, third parties and IT providers are explicitly permitted to build and use it. Implementation guidance itself lives on a public wiki rather than behind a paywalled specification, maintained by the standard-setting groups, which is a genuine advantage for a team scoping this work without an enterprise support contract in place. It is also why we point clients doing their own reading toward the EASD implementation guide rather than a marketing page. This is the same distribution layer our travel software development guide covers at the platform level, and it sits next to, rather than inside, the GDS and booking connections our aviation software development practice builds for carriers and operators on the airline side.

The Offer and Order lifecycle message by message

Scoping NDC integration as one API is the estimating mistake we check for first, because the standard is actually a set of separate transaction messages, each with its own request shape, response shape and failure modes. Shopping starts with AirShopping, which supports both a specific search and a flexible, broader shopping experience for anonymous or personalized requests. Pricing runs through OfferPrice, which can return ancillary options first and final pricing once a selection is made. SeatAvailability returns seat maps with any premium-seat fees already integrated, and ServiceList returns the ancillary catalog that matches the seller's request qualifiers and flights.

Booking itself is OrderCreate, and the IATA EASD implementation guide is precise about who talks to whom: OrderCreate is the outbound message that a Seller or Aggregator sends to the Airline, and that an ORA sends to a POA where that role applies, carrying the details of a selected Offer and requesting that the ORA or POA create an Order. ORA is the Offer Responsible Airline and POA is the Participating Offer Airline, two roles that matter once interline or codeshare offers are in scope, and neither appears as an obvious label in a typical shopping UI. Lookup and search are two different messages, not one: OrderRetrieve fetches a specific Order by its identifier, and it is the only message that can retrieve an Order using something other than that identifier, while OrderList retrieves Orders matching search criteria. OrderHistory requests the transaction history and audit trail for a given Order, which we treat as a first-class scoping item rather than a nice-to-have, because support teams ask for it the first week after launch. A platform grounding recommendations or conversational search against AirShopping and OfferPrice responses, rather than a cached fare snapshot, is exactly the pattern our AI travel agent development work depends on, since a live NDC shop call is what keeps an assistant's answers accurate against real inventory.

Aggregator or direct connect

NDC defines a Distribution Chain with named roles, and the choice of where your platform sits in that chain is the real architectural decision, not an implementation detail to settle later. The chain exists, in the standard's own words, to help "Airlines identify the parties within the transaction from the Customer (via any intermediaries) to the Airline." The three roles are Seller, Distributor and Carrier, and a Distributor is defined simply as an organization that provides a distribution capability, a definition broad enough to cover both a consolidator and what the market calls an aggregator.

The commercial consequence sits in a single line of IATA's Distribution Chain page: whichever Distributor is the last one before the airline, the party closest to the carrier in the chain, carries responsibility for populating that structure. Whoever occupies that final position before the carrier owns the obligation to populate the chain data correctly on every message. Going through an aggregator moves that obligation onto the aggregator's build. Going direct makes your own platform the last Distributor, and that data-population work becomes yours.

Aspect	Aggregator	Direct connect
Chain data population	Handled by the aggregator	Owned by your platform
Per-airline onboarding	One integration, many carriers	Separate onboarding for each carrier
Commercial and content control	Limited to what the aggregator exposes	Full control over offer handling
Best fit	Broad coverage across many airlines fast	A small set of priority carriers, or a differentiated servicing experience

Neither option is universally right. We tend to recommend an aggregator first, for coverage, then a direct connect for the two or three carriers that drive the most volume or need servicing behavior the aggregator cannot expose. The test we actually apply is qualitative, not a volume threshold: direct connect is worth taking on the chain-data obligation only for carriers where servicing volume, not search volume, justifies owning the relationship, since the chain-data work pays for itself in post-sale handling, not in shopping traffic.

Servicing after the sale

Servicing is where a lot of NDC scoping goes wrong, mostly because teams assume a booking flow is the whole job and treat post-sale as an afterthought. There is no separate refund message. Exchanges run through OrderChange, which the EASD guide describes as requesting a modification by specifying which Order Items to change and which Offer Items to replace them with. Priced change options, including any refund due, come back through OrderReshop, which responds with new offers in the context of the existing Order and includes any additional collection or refund figure directly in that response. A servicing screen that only calls OrderChange and has nowhere to render a reshop response is an incomplete build, and we catch that gap early by scoping both messages together rather than one after the other.

OrderRules is the fare-conditions message, returning fare, condition, product and compliance information on request. What it does not return is machine-readable logic: the content is descriptive text meant for a human to read, not a rules engine to parse, and a build that tries to derive automated change-fee decisions from OrderRules content alone is working against the message's own design. Finally, OrderChangeNotif is a push, not a pull: it sends an unsolicited notification when an Order changes voluntarily or involuntarily, which means the integration needs a listener endpoint capable of receiving an inbound call, not only a client that talks outward. Skipping that listener is the gap we look for first when reviewing a partial NDC build.

Making OrderCreate safe to retry is a pattern we build into NDC integrations rather than improvising it per carrier. Before the call goes out, we generate and store a client-side idempotency key against the order attempt, so a timeout or a dropped connection never has to guess whether the airline actually created the order. If the OrderCreate response is lost, OrderRetrieve becomes the reconciliation read: we look the order up by the same key, or by passenger and itinerary, before considering a retry, rather than resubmitting blind. OrderChangeNotif then closes the loop after booking, writing any voluntary or involuntary change back onto that same order record so the servicing screen never has to reconcile two different sources of truth for one booking.

What IATA publishes about NDC maturity

Buyers frequently ask whether a vendor is "NDC certified," and the honest answer today runs through IATA's current public program, the ARM index, not a certification level. The index is structured around four modules, covering workflow capability, partnership deployment, value-capture maturity and offer and order readiness, and IATA states that the index evaluates organizations "across their technical capabilities, scalability of partnerships across the retailing value chain, and maturity in capturing potential value". Reviewed organizations, including system providers, sellers and airlines, appear in a public registry that anyone can check before signing a vendor contract.

What the registry is not, IATA states plainly on the ARM index registry page: "nor does it validate, certify or endorse any commercial products that may be derived from the usage of capabilities validated under the ARM index". A vendor's presence on that registry tells you their organizational capability has been reviewed. It does not tell you their specific product is IATA-certified, because IATA is explicit that no such certification exists for a commercial product built on top of it.

Sequencing the integration

Once the message set and the distribution-chain decision are settled, the order of engineering work follows a predictable sequence, and jumping it is what turns a bounded NDC scope into an open-ended one. We run it in four steps.

1. Confirm the exact message scope against the buyer's use case: shopping and booking alone is a much smaller build than shopping, booking and full post-sale servicing.
2. Decide aggregator or direct connect per carrier, since a mixed model, aggregator for breadth and direct for priority airlines, is common and needs to be architected as such from the start rather than retrofitted.
3. Design and build the OrderChangeNotif listener before launch, not after the first involuntary schedule change arrives from a live carrier.
4. Check the ARM index registry status of any vendor or airline partner involved, so procurement decisions rest on a reviewed capability record rather than a marketing claim.

Worth flagging before that sequence starts: NDC and ONE Order are separate IATA standards with separate program pages, and ONE Order's aim of phasing out PNRs, e-tickets and EMDs into a single record is not something an NDC integration delivers on its own. A platform that also needs a booking engine sitting behind this message set, rather than only the airline-facing side of it, should scope that build alongside our booking engine development guide, since the two pieces of work share data model decisions that are far cheaper to make once than to unwind later. Of everything in a partial NDC build, the OrderChangeNotif listener is the piece a travel software roadmap most often leaves unbudgeted, because a build that only talks outward to an airline has no way to receive the involuntary schedule change the message is designed to push back.

FAQ

Last updated: September 5, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. What is NDC API integration?

  Copy link Copies a direct link to this answer to your clipboard.

  NDC (New Distribution Capability) is an XML-based data exchange standard organized around Offer and Order management, launched by IATA and open to any implementer, not only IATA members. Integrating against it means implementing the message set an airline exposes for offer generation and order servicing, not adding a single new booking endpoint to an existing flow.

• Is NDC a replacement for GDS booking?

  Copy link Copies a direct link to this answer to your clipboard.

  Not by itself. NDC defines a Distribution Chain with named roles; going through an aggregator, which acts as a Distributor, keeps the chain-data obligation on the aggregator's side, while a direct connection makes your platform the last Distributor before the airline and moves that obligation onto your own build.

• What messages does an NDC integration need to implement?

  Copy link Copies a direct link to this answer to your clipboard.

  At minimum AirShopping for search, OfferPrice for pricing, OrderCreate for booking, OrderChange and OrderReshop for servicing and exchanges, OrderRetrieve or OrderList for lookup and OrderChangeNotif, an unsolicited push message that requires a listener rather than only a client.

• Does IATA certify NDC integrations?

  Copy link Copies a direct link to this answer to your clipboard.

  IATA's current public program is the ARM index, which reviews technical capability, partnership scalability and value-capture maturity and publishes a registry of reviewed organizations. IATA states plainly that this registry does not validate, certify or endorse any commercial product built on the reviewed capabilities.

• How do refunds and exchanges work in NDC?

  Copy link Copies a direct link to this answer to your clipboard.

  Exchanges run through the OrderChange message, which specifies which Order items to change and which Offer items replace them. Priced change options, including any refund due, come back through OrderReshop.

  There is no separate refund message: the reshop response itself carries the additional collection or refund figure.

• Does NDC replace the PNR and e-ticket?

  Copy link Copies a direct link to this answer to your clipboard.

  Not on its own. A separate IATA initiative called ONE Order aims to combine PNRs, e-tickets and EMDs into a single Order record, but ONE Order is its own XML standard with its own program page.

  Implementing NDC messages does not automatically deliver a single-order record.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.