NDC Key Terms for Beginners

The travel industry has communicated through cryptic codes and fixed-format messages for decades. A fare code like "Y26NR" meant something specific to trained agents but nothing to everyone else. NDC (New Distribution Capability) changes that by replacing opaque codes with structured, descriptive data — but it introduces its own vocabulary in the process.

Understanding NDC terminology is not an academic exercise. It is a practical requirement for anyone working in airline distribution: product managers designing booking flows, engineers building API integrations, operations teams handling customer support, and commercial leaders evaluating NDC strategy. Without a shared vocabulary, cross-functional teams struggle to communicate, requirements get misinterpreted, and implementations go off track.

This guide covers every essential NDC term you need to know, organized around the traveler journey — from searching for flights to managing a booking after purchase. Each term includes a clear definition, practical example, relationship to other concepts, and common misconceptions to avoid.

Everything in NDC revolves around two foundational ideas: the Offer and the Order. These concepts replace the GDS model of PNRs and fare filings, and understanding the distinction between them is the single most important step in learning NDC.

An Offer is the airline's product proposal presented during the shopping phase. It represents what the airline is willing to sell to a specific traveler at a specific moment in time.

Think of an offer like a product listing on an e-commerce site. When you search for flights from London to New York on a specific date, the airline responds with one or more offers. Each offer describes a complete travel product: the flight segments, the cabin class, the fare brand, the price, included services (like checked baggage), optional add-ons (like seat selection or lounge access), flexibility rules, and any applicable penalties or conditions.

Key characteristics of an Offer:

• Time-bound — Offers can expire or change. Airline availability and pricing are dynamic, so an offer shown at 10:00 AM may not be identical at 10:05 AM.
• Contextual — Offers may be tailored based on traveler loyalty status, corporate agreements, market, or other factors. Two travelers searching the same route may receive different offers.
• Rich in detail — Unlike a GDS fare line, an NDC offer includes descriptive names, images, service descriptions, and structured rules that can be displayed directly to the traveler.
• Multi-component — An offer can include multiple offer items (flight segments, ancillaries, services) grouped into a single proposal.

Practical example: A traveler searches for JFK to LHR on June 15. The airline returns three offers: Economy Basic ($450, no checked bag, non-refundable), Economy Flex ($580, one checked bag, changeable for a fee), and Business Class ($2,100, two checked bags, lounge access, fully refundable). Each offer is a complete product description — not just a price.

Common misconception: An offer is not a reservation. It is a proposal. Nothing is booked until the offer is accepted and an order is created. Many beginners confuse seeing an offer with having a confirmed booking.

An Order is the record created after a traveler accepts an offer and completes the booking process. It is the definitive record of what was purchased and becomes the starting point for all post-booking actions.

If an offer is the product listing, the order is the confirmed purchase receipt. It contains passenger details, the services that were purchased, payment information, fulfillment status, and a unique order identifier assigned by the airline.

Key characteristics of an Order:

• Persistent — Unlike offers, orders are durable records. They exist until the travel is completed, cancelled, or otherwise resolved.
• State-driven — Orders move through states: pending payment, confirmed, ticketed, partially serviced, cancelled, refunded. Each state determines what actions are possible.
• Servicing entry point — Every post-booking action (cancellation, refund, exchange, adding a bag) begins by retrieving the order and understanding its current state.
• Multi-identifier — An order may have identifiers from the seller, the aggregator (if used), and the airline. Mapping these correctly is critical for operational reliability.

Practical example: A traveler selects the Economy Flex offer from the previous example, enters passenger details, provides payment, and receives a confirmed order. The order includes the passenger name, flight segments, one checked bag entitlement, the total price paid, the airline order ID (e.g., "ORD-ABC123"), and the current state ("Confirmed"). Later, when the traveler wants to add a second bag, the servicing flow retrieves this order to determine what is possible.

Common misconception: An order is not the same as a PNR (Passenger Name Record). While both represent a booking, a PNR is a GDS-specific concept tied to the legacy reservation system. An NDC order is a richer, more flexible record that encompasses the full commercial transaction — not just the reservation.

Understanding how offers become orders clarifies the entire NDC workflow. Here is the typical sequence:

1. Shopping request — The seller sends origin, destination, dates, and passenger details.
2. Offer response — The airline returns one or more offers with full product descriptions.
3. Offer selection — The traveler or agent chooses an offer.
4. Price confirmation — The seller verifies the offer is still available at the expected price (critical because offers can change).
5. Order creation — Passenger details, payment, and selected services are submitted. The airline creates the order.
6. Order confirmation — The seller receives the order with a unique identifier and current state.
7. Servicing — Post-booking actions are performed against the order throughout its lifecycle.

This lifecycle is the backbone of every NDC integration. Every term in this guide relates to one or more stages in this flow.

The shopping phase is where travelers discover and compare airline products. Several key terms define how this process works in NDC.

A Shopping Request is the initial query sent to an airline or aggregator to retrieve available offers. It typically includes origin and destination airports, travel dates, number and type of passengers (adult, child, infant), cabin preference, and trip type (one-way, round-trip, multi-city).

Advanced shopping requests may also include loyalty program identifiers, corporate account codes, or market context — information the airline can use to tailor offers. The quality and completeness of the shopping request directly affects the relevance and accuracy of the offers returned.

Why it matters: A poorly constructed shopping request may return incomplete offers, miss available products, or trigger errors. Seller platforms must validate request data before submission and handle incomplete or delayed responses gracefully.

An Offer Item is an individual component within an offer. An offer may contain multiple offer items, each representing a distinct product element: a specific flight segment, a baggage allowance, a seat selection, a meal, or any other service the airline is proposing to sell.

Practical example: An offer for a round-trip booking might contain four offer items: outbound flight (JFK to LHR), return flight (LHR to JFK), one checked bag included in the fare brand, and an optional preferred seat add-on. The traveler can accept the entire offer or, in some implementations, select individual offer items.

Relationship to other terms: Offer items become Order Items when the offer is accepted and the order is created. The mapping between offer items and order items is important for servicing, as each order item may have its own servicing rules.

Price Confirmation (sometimes called Offer Price) is the step where the seller verifies that a selected offer is still available at the price and conditions originally displayed. This is a critical safeguard in NDC workflows.

Because airline availability and pricing are dynamic, the offer shown during shopping may no longer be valid by the time the traveler is ready to book. Price confirmation catches these changes before payment is processed, preventing frustrating situations where a traveler pays one price but receives a different product.

Best practice: Always perform price confirmation before order creation. Display any price changes to the traveler and require explicit acceptance before proceeding. This protects both the customer experience and the seller's operational integrity.

A Branded Fare is a named fare product that bundles specific services and conditions into a recognizable package. Examples include "Basic Economy," "Main Cabin," "Premium Economy," and "Business Flex." A Fare Family is the group of related branded fares for the same route and cabin.

In the GDS world, fares were identified by cryptic booking class codes (Y, B, M, Q, etc.) that required agent expertise to interpret. NDC branded fares replace these with human-readable names and structured descriptions of what is included.

Practical example: An airline might offer three branded fares on the same flight: "Lite" (carry-on only, no changes), "Standard" (one checked bag, changes for a fee), and "Flex" (two checked bags, free changes, priority boarding). Each fare is a distinct product with clear value differentiation — not just a price difference.

Why it matters for sellers: Branded fares enable meaningful product comparison. Seller platforms should display fare family attributes (included services, change policies, baggage allowances) side by side so travelers can make informed decisions based on value, not just price.

Ancillaries (also called Services in NDC terminology) are optional products and services sold alongside or around the flight. The global airline ancillary market exceeded $100 billion in 2024, making this one of the most commercially significant aspects of NDC.

Ancillaries fall into several categories:

• Baggage — Checked bags, extra bags, overweight bags, sports equipment
• Seating — Preferred seats, extra-legroom seats, exit row seats, seat selection fees
• Meals and refreshments — Pre-ordered meals, special dietary options, premium dining
• Comfort and convenience — Lounge access, priority boarding, fast-track security, Wi-Fi
• Flexibility — Changeable tickets, refundable fares, travel insurance
• Bundles — Combinations of ancillaries packaged together at a discounted price (e.g., "Comfort Bundle" including seat, bag, and priority boarding)

Key distinction: Some ancillaries are included within a branded fare (e.g., one checked bag in Economy Flex), while others are optional add-ons the traveler can purchase separately. A good seller interface makes this distinction clear so travelers understand the total value of each offer.

Timing matters: Some ancillaries are offered during shopping, some during booking, and some only after an order exists. Airlines differ significantly in what they support at each stage. Seller platforms must handle this variation gracefully.

In NDC, a Service Definition (or Service Description) is the structured data that describes an ancillary product. It includes the service name, description, price, eligibility rules, applicable passengers or segments, and any restrictions or conditions.

This is a significant improvement over the GDS model, where ancillary information was often conveyed through cryptic service codes that agents had to memorize or look up. NDC service definitions can be displayed directly to travelers in plain language.

Practical example: A service definition for a preferred seat might include: "Preferred Seat — Row 12, Window — $25 — Available for Adult passengers on segments JFK-LHR and LHR-JFK — Includes extra legroom — Non-refundable after check-in."

Servicing is the set of actions that occur after an order exists. It is widely considered the most complex part of NDC implementation — and the area where airline variation is most pronounced.

Order Retrieval is the action of fetching the current state of an existing order using its unique identifier. This is the first step in any servicing workflow — you must understand what the order contains and what state it is in before you can modify it.

The retrieved order includes passenger information, purchased services, payment status, fulfillment state, and any servicing history. Seller platforms should store the airline order ID securely and use it for all subsequent servicing requests.

Operational importance: Support teams rely on order retrieval to investigate customer issues, verify booking details, and determine what servicing actions are available. Fast, reliable order retrieval is essential for customer satisfaction.

A Cancellation is the action of voiding an existing order before or after travel. The rules governing cancellations vary significantly by airline, fare type, and timing.

Key considerations:

• Some fares are non-refundable — cancellation results in no refund or only a tax refund.
• Some cancellations must occur before ticketing; others are allowed after.
• Partial cancellations (one passenger on a multi-passenger order, one segment on a multi-segment itinerary) are not universally supported.
• The cancellation response may include refund amount, processing timeline, and any applicable fees.

Common misconception: Cancellation does not automatically mean a full refund. The refund amount depends on the fare rules, timing, and airline policy. Seller platforms must communicate the expected refund outcome clearly before the traveler confirms the cancellation.

A Refund is the financial process of returning money to the traveler after a cancellation or eligible change. In NDC, refund workflows are tightly coupled with order state and payment records.

Refunds may process back to the original payment method, as a travel credit, or through a separate refund mechanism. The timeline and tracking method vary by airline. Some airlines provide immediate refund confirmation; others process refunds over several business days.

Best practice: Track refund status independently from order status. A cancelled order does not necessarily mean the refund has been processed. Seller platforms should provide visibility into refund state for both support teams and travelers.

An Exchange (or voluntary change) is the action of modifying an existing order — typically changing flight dates, times, or routes. Exchanges are among the most complex NDC servicing workflows.

An exchange involves several steps: retrieving the current order, determining eligibility for change, obtaining a repriced offer for the new itinerary, calculating fare differences and penalties, collecting additional payment (or processing residual value), and updating the order.

Why exchanges are difficult: Every airline implements exchanges differently. Some support end-to-end exchange through NDC. Others require partial manual processing. Some calculate penalties automatically; others require manual fare rule interpretation. Seller platforms must handle this variation with clear user communication and robust error handling.

A Schedule Change occurs when the airline modifies a flight time, date, or route after the order has been created. Unlike voluntary exchanges initiated by the traveler, schedule changes are initiated by the airline and typically come with different rules and options.

When a schedule change occurs, the traveler may have several options: accept the new schedule, choose an alternative flight offered by the airline, or cancel with a full refund. How these options are communicated and processed varies by airline.

Operational challenge: Some airlines proactively notify sellers of schedule changes through NDC. Others only surface changes during order retrieval, meaning the seller discovers the change when the traveler contacts support. Building proactive schedule change detection is a significant operational investment.

Beyond the traveler-facing concepts, several technical terms define how NDC systems are built and operated.

Normalization is the process of converting airline-specific NDC responses into a consistent internal model that a seller platform can work with regardless of which airline produced the data.

Without normalization, every airline integration introduces different field names, status values, error codes, and data structures into the seller platform. This creates inconsistency in the user experience, complexity in the business logic, and confusion in operational tooling.

Analogy: Imagine receiving product catalogs from 10 different suppliers, each in a different format — some in Excel, some in PDF, some in handwritten notes. Normalization is like creating a standard template that all catalogs are converted into before they reach your inventory system.

What gets normalized:

• Offer structures and pricing formats
• Service types and descriptions
• Order status values and state transitions
• Error codes and messages
• Passenger data formats
• Currency and tax representations

Important note: Normalization is not about stripping airline-specific richness. It is about creating a consistent framework that preserves useful detail while absorbing structural variation. A well-designed normalization layer lets you add new airline connections without redesigning your platform.

An Airline Adapter is a software component that translates between a seller platform's canonical domain model and a specific airline's NDC implementation. Each airline gets its own adapter.

The adapter handles authentication, request construction, response parsing, version management, error translation, and airline-specific workflow logic. It is the isolation layer that prevents airline variation from leaking into the rest of the platform.

Best practice: Keep adapters narrow and focused on translation. Do not embed business logic, ranking rules, or user experience decisions in adapters. Those belong in the core platform where they benefit from consistency across all airlines.

NDC messages follow structured schemas defined by IATA. Different Schema Versions (17.2, 18.x, 21.3, 24.x) represent different iterations of the standard, with varying levels of capability and structure.

Airlines use different schema versions, and many are slow to upgrade. The 17.2 and 18.x families still dominate production deployments, while 21.3 and 24.x are growing. Some airlines run multiple versions across different markets or channels.

Why it matters: Schema version differences affect which fields are available, how data is structured, and which workflows are supported. Seller platforms must handle version differences gracefully, either through version-aware adapters or through normalization that accounts for version-specific variations.

An Aggregator is a technology provider that connects to multiple airlines' NDC APIs and exposes a single, normalized API to sellers. Examples include Accelya, Duffel, AirGateway, Verteil, TPConnects, and the aggregator platforms operated by Amadeus, Sabre, and Travelport.

Aggregators reduce integration complexity by handling airline-specific differences on behalf of the seller. Instead of building and maintaining separate connections to each airline, a seller integrates once with the aggregator and gains access to all airlines in the aggregator's network.

Trade-off: Aggregators simplify integration but may reduce control over offer presentation and servicing workflows. Normalization sometimes means losing airline-specific richness. The decision to use an aggregator versus building direct connections depends on volume, airline mix, engineering capacity, and commercial strategy.

Certification is the process by which an airline validates that a seller's NDC integration handles their specific implementation correctly before granting production access. It typically involves demonstrating specific shopping, booking, and servicing scenarios in a sandbox environment.

Certification timelines vary widely: 4–8 weeks for airlines with mature NDC programs, 8–16 weeks for developing programs, and 12–24+ weeks for airlines new to NDC. Certification is one of the most underestimated phases of NDC implementation.

Best practice: Treat certification as part of your delivery lifecycle, not as an administrative step after development. Build automated test suites, keep trace logs for every request, and certify servicing at the same time as shopping — not as a separate later phase.

Understanding how NDC terms relate to each other is as important as understanding each term individually. Here are the most critical relationships:

Misconception 1: "NDC is just a new API format." NDC is not just a technical change. It represents a fundamental shift from fare-based distribution to offer-based retailing. The vocabulary reflects this: offers, orders, services, and servicing are retailing concepts, not just data formats.

Misconception 2: "An offer is a booking." An offer is a proposal, not a reservation. Nothing is confirmed until an order is created. This distinction is critical for understanding the NDC workflow.

Misconception 3: "NDC replaces GDS entirely." NDC and GDS are complementary. GDS provides broad access and standardized workflows; NDC provides richer content and airline control. Most sellers use a hybrid strategy.

Misconception 4: "All airlines implement NDC the same way." Every airline implements NDC differently — different schema versions, different error handling, different servicing capabilities, different certification processes. Normalization and adapters exist specifically to manage this variation.

Misconception 5: "Servicing is just the reverse of booking." Servicing is not simply undoing a booking. It involves complex state management, airline-specific rules, payment reconciliation, and partial action handling. Servicing is significantly harder than shopping and booking combined.

1. Start with the traveler journey. Map each term to a stage in the journey: search (shopping request), compare (offers), select (offer selection), confirm (price confirmation), book (order creation), manage (servicing). This creates a mental model that is intuitive and memorable.
2. Learn the Offer-Order distinction first. Everything else builds on this foundation. If you understand what an offer is and what an order is, the rest of the vocabulary falls into place.
3. Use consistent terminology internally. Ensure your product, engineering, and operations teams use the same terms. Avoid mixing GDS terminology (PNR, booking class) with NDC terminology (order, fare brand) without clear definitions.
4. Document airline-specific variations. When you encounter airline-specific differences in how terms are implemented, document them. This becomes a valuable reference for your team as you add more airline connections.
5. Build your internal model around NDC concepts. Design your data structures, APIs, and user interfaces around offers, orders, and services — not around legacy GDS concepts. This makes your platform more adaptable as NDC evolves.

• Offer = the airline's product proposal during shopping. Time-bound, contextual, and rich in detail.
• Order = the confirmed purchase record. Persistent, state-driven, and the entry point for all servicing.
• Ancillaries / Services = optional products (bags, seats, meals, lounge) sold alongside the flight. A $100B+ market.
• Branded Fares = named fare products that bundle services and conditions into recognizable packages.
• Servicing = post-booking actions (cancellation, refund, exchange, schedule change). The hardest part of NDC.
• Normalization = converting airline-specific responses into a consistent internal model. Essential for multi-airline platforms.
• Adapter = the translation layer between your platform and each airline's specific NDC implementation.
• Certification = the airline's validation process before granting production access. Plan for 4–16 weeks.
• Aggregator = a provider that normalizes multiple airlines into a single API, reducing integration complexity.
• Schema Version = the iteration of the NDC standard (17.2, 18.x, 21.3, 24.x) that an airline implements.

Mastering these terms gives you the foundation to understand NDC workflows, communicate effectively across teams, and make informed decisions about NDC strategy and implementation.