NDC API integration connects a travel portal to airline-direct content that is no longer available through traditional GDS channels. As airlines progressively move ancillaries, branded fares, and personalized pricing off the GDS rail and onto NDC, every OTA and travel agency that wants competitive flight inventory in 2026 and beyond needs an NDC strategy.
This page explains what NDC is, how the order/offer model differs from GDS, which supplier sources to use, the IATA certification levels, integration patterns, and how the adivaha platform handles NDC for you so your team writes one connector rather than dozens.
For the broader API architecture context, read alongside our hub on integration with adivaha. For GDS coverage, see GDS connectivity. For low-cost carrier content, see LCC content. For the commercial portal that bundles all three, see our hub on adivaha's platform.
Talk to our team for a 30-minute technical walkthrough: NDC supplier coverage for your priority airlines, certification level requirements, and how integration fits your current platform.
Book a technical call
What Is NDC and Why It Matters
NDC, or New Distribution Capability, is an IATA-led XML-based standard that lets airlines distribute richer content directly to travel sellers. The standard was introduced in 2012 and has steadily expanded in adoption. Today most major carriers distribute meaningful inventory exclusively through NDC.
The shift matters for three commercial reasons. First, content richness: NDC carries ancillaries (seats, baggage, meals, lounge access), branded fare attributes (refundability, change rules, mileage tier), and personalized offers that the GDS-edited-fare model cannot represent. Second, distribution economics: airlines pay lower distribution costs on NDC channels than on GDS, and they are progressively shifting volume to NDC to capture the savings. Third, competitive parity: an OTA without NDC sees a thinner subset of the airline's offers than one with NDC. Over time, this gap widens.
For practical portal planning, NDC has moved from a "nice to have" to "baseline expectation" for any portal with serious flight volume. Portals that delay NDC integration accept progressively narrower content coverage relative to competitors.
NDC vs GDS: How Content Differs
The architectural difference between NDC and GDS is the location of offer creation.
| Aspect | GDS | NDC |
|---|---|---|
| Offer creation | GDS aggregates filed fares | Airline creates the offer |
| Persistent state | PNR (re-priced on change) | Order (servicing-capable) |
| Content depth | Fare + booking class | Fare + ancillaries + branded attributes |
| Ancillaries | Limited (mostly post-booking) | Full (offer-time) |
| Personalization | Loyalty number only | Full personalization at offer time |
| Distribution cost | Higher | Lower |
| Standardization | High (consistent across airlines) | Moderate (XML schema with carrier variations) |
The practical implication: a portal that supports both GDS and NDC sees the broadest content. A portal that supports only GDS sees a progressively narrower view as airlines shift inventory to NDC. A portal that supports only NDC misses the long tail of smaller carriers that still distribute primarily through GDS.
NDC API Supplier Coverage
Three categories of suppliers provide NDC content. The right mix depends on your priority airlines and traveler markets.
Aggregator NDC (the practical default)
Amadeus NDC aggregates NDC content from over 60 airlines including major carriers like Lufthansa Group, Singapore Airlines, Qantas, and Iberia. Available through the Amadeus platform with one technical integration. Best for portals already on the Amadeus stack or looking for broad coverage with minimal engineering.
Sabre NDC aggregates NDC content with strong North American carrier coverage. Available through the Sabre platform. Best for portals already on Sabre or those serving North American traveler bases.
Travelport NDC aggregates content with global coverage and a focus on European and Middle Eastern carriers. Available through the Travelport stack.
Airline-direct NDC (for richer single-carrier content)
Major airlines offer direct NDC APIs that often expose richer ancillary content than the aggregator routes. Worth considering when a specific airline is critical to your routes.
- Lufthansa Group NDC (Lufthansa, SWISS, Austrian, Brussels, Eurowings) - one of the earliest and most mature direct NDC APIs.
- British Airways and the wider IAG group (Iberia, Aer Lingus, Vueling).
- Singapore Airlines NDC with extensive ancillary coverage.
- Qantas and Jetstar NDC.
- Emirates NDC for premium-cabin and ancillary content.
- American Airlines, United, and Delta NDC for North American distribution.
- Air France-KLM, Turkish Airlines, Cathay Pacific, and many others.
Aggregator-of-aggregators (the adivaha approach)
The adivaha platform bundles aggregator NDC and selected airline-direct NDC into a single connector. Your engineering team writes one integration; we maintain the upstream connectors. For most portals this is the right starting point - direct airline NDC integration becomes worth the engineering investment only when a specific carrier dominates your routes.
The Order/Offer Model
NDC introduces a fundamentally different transaction model from GDS. Understanding it shapes integration design.
Offer (the priced quote)
The airline creates a complete Offer that includes the base fare, branded-fare attributes (refundability, change rules, baggage allowance, mileage accrual rules), and any ancillaries the traveler may want (extra bags, seat selection, lounge access). The Offer is timestamped and may have a short validity window (typically 15-30 minutes). The seller cannot modify the price within an Offer - they accept or reject as-is.
Order (the booking)
Accepting an Offer creates an Order - the persistent record of the booking. Unlike a GDS PNR, the Order is owned by the airline and serviced through NDC APIs for the entire booking lifecycle. Adding ancillaries, processing changes, requesting refunds, and even checking in (in some implementations) happen against the Order without re-querying the GDS.
Servicing
Post-booking changes use NDC servicing APIs: OrderChange, OrderReshop, OrderCancel, ServiceList. The seller queries the Order, requests a change, and receives a new Offer (which may incur fees) that they can accept or reject. The model is more transparent to the traveler than the GDS re-pricing flow.
Why this matters operationally
Portals built originally for GDS often struggle with NDC because their data model assumes PNR-style state. A clean NDC integration requires Order-aware persistence in your booking database, separate post-booking servicing flows, and clear UI affordances that distinguish NDC and GDS bookings (because the change/refund rules differ).
IATA NDC Level Certification
IATA certifies sellers against four NDC capability levels. Each level represents progressively richer NDC support.
| Level | Capability | Typical adoption |
|---|---|---|
| Level 1 | Offer/Order basic shopping | Entry point - rarely production |
| Level 2 | Offer/Order + payment | Minimum for production |
| Level 3 | Adds servicing (change, refund, ancillary post-booking) | Recommended launch target |
| Level 4 | Full personalization, dynamic offers | Mature implementations |
Most production OTAs target Level 3 at launch and expand to Level 4 over time. The adivaha platform supports certification readiness across all four levels - you inherit the platform certification on connection rather than building it yourself.
Implementation Patterns
Three architecture choices shape any NDC implementation.
1. Adapter vs. native
The adapter pattern treats NDC like another supplier - normalize the NDC offer to your existing fare model, route bookings through your existing booking engine. Quick to ship, but flattens the richness of NDC content (you lose branded-fare attributes and rich ancillary metadata in normalization).
The native pattern keeps NDC offers in NDC-shaped data structures all the way through to the booking record. Preserves richness but requires a parallel servicing path. Most mature implementations land here.
2. Offer expiry and re-shop
NDC offers have short validity windows. The traveler may take 5-15 minutes to complete checkout. If the Offer expires, the platform must either re-shop (request a new Offer) and warn the traveler about any price change, or hold the original Offer with a "pricing as of X" note. Both have UX implications - decide the pattern before launch.
3. Mixed-content search results
When search results include both NDC and GDS fares for the same route, the platform must merge them coherently. Considerations: how to sort (by price? by content richness?), how to label (clearly distinguishing NDC ancillaries from GDS post-booking adds), how to handle ties.
Pricing and Plans
adivaha NDC integration is included in our two standard plans plus a custom tier for bespoke requirements.
Standard: USD 999 setup + USD 99/month
Full NDC integration through Amadeus NDC, Sabre NDC, and select airline-direct connectors. Sandbox access, REST/JSON documentation, ancillary support, order servicing. 7-day free trial. See full pricing.
Custom (enterprise scope)
Same NDC coverage as Monthly, billed annually. Includes the B2B sub-agent module for portals running agent networks. Saves USD 789 a year vs Monthly billing.
Custom
For portals needing additional airline-direct NDC integrations beyond our standard roster, custom certification levels, or enterprise SLA wording. Talk to sales for scoping.
Sandbox and Documentation
All plans include sandbox access for NDC integration testing without committing to production. The sandbox exposes test Offers and Orders for the major airline groups, supports the full servicing API surface, and is available within 24 hours of account creation. API documentation lives at docs.adivaha.com with REST/JSON examples, Postman collection, and OpenAPI specification for the NDC endpoints.
Why adivaha for NDC Integration
Three reasons portals choose adivaha as their NDC integration partner.
Aggregated supplier coverage. One integration gives you NDC content from Amadeus NDC, Sabre NDC, and over a dozen airline-direct NDC connectors. Your engineering team writes one connector; we maintain the upstream relationships.
Certification readiness. The platform supports IATA NDC Level 3 and Level 4 certification. You inherit the certification posture on connection rather than spending months on it yourself.
Mature operations. Order servicing, ancillary handling, refund workflows, and reconciliation are all production-tested across hundreds of portal deployments. You skip the operational learning curve.
FAQs
Q1. What is NDC and why does it matter for travel portals?
NDC stands for New Distribution Capability - an IATA-led standard that lets airlines distribute richer content (branded fares, ancillaries, personalized pricing) directly to sellers, bypassing the GDS edited-fare model. For OTAs, NDC unlocks airline content not available through legacy channels: bundled fares, seat selection, baggage upgrades, lounge access.
Q2. How is NDC different from GDS?
GDS aggregates filed fares centrally; NDC has airlines create offers directly. NDC content is richer (ancillaries, branded fares) but less standardized across airlines. Most production portals run both.
Q3. Where can I source NDC content?
Three sources: aggregator NDC (Amadeus, Sabre, Travelport), individual airline-direct NDC APIs (Lufthansa, Singapore, BA, Emirates and more), or a platform aggregator like adivaha that bundles both behind one connector.
Q4. What is IATA NDC Level certification?
IATA certifies sellers at Levels 1 through 4. Level 1 is basic, Level 4 is full personalization. Most portals target Level 3 (offer + order + servicing) at launch. adivaha supports certification readiness across all four.
Q5. How does the order/offer model work?
The airline sends a priced Offer. The seller accepts to create an Order - the persistent booking record. Servicing (changes, refunds, ancillaries) happens against the Order through NDC APIs, without GDS re-pricing.
Q6. What ancillaries are available through NDC?
Seat selection, baggage, meals, lounge access, WiFi, priority boarding, branded fare attributes, insurance, ground transfers, and in some cases loyalty enrollment. Coverage varies by airline.
Q7. How long does NDC integration take?
Aggregator NDC: 4 to 8 weeks. Airline-direct NDC: 6 to 14 weeks per carrier. On the adivaha platform: 1 to 3 weeks because the integrations are centralized.
Q8. What does NDC integration cost?
adivaha NDC is included in the Standard plan at USD 99/month (with USD 999 one-time setup) and the Standard plan at (included in Standard above). No per-transaction fees by airline. Building NDC in-house typically costs USD 50K-200K plus maintenance.
Q9. Can I mix NDC and GDS in the same booking flow?
Yes. Search results merge NDC and GDS fares. Booking and servicing paths differ behind the scenes (orders vs PNRs) and the platform routes correctly. adivaha handles this routing transparently.
Q10. What is the future of NDC?
IATA targets 100 percent of major airlines distributing NDC by the end of the decade. For portals, NDC is moving from differentiator to baseline. Starting now positions you for the next 3 to 5 years of content access.