NDC Guide

This guide discusses what NDC New Distribution Capability, an XML standard for exchanging data that supports airlines in distributing their content directly to online travel agencies. See the NDC Guide. is and basic differences in support or workflow for NDC and GDS Global Distribution System. A GDS aggregates and distributes air, hotel, and car rental content such as schedules, fares, and upsells. In the JSON APIs, GDS content is distributed from Travelport. content.

Most topics in this online help are for both GDS and NDC content, with differences between them noted as applicable. The NDC menu at the top of every page in this online help groups the topics that apply only to NDC.

Related Content: JSON APIs Guide, NDC FAQs

In this topic:

• NDC Basic Concepts
  • What is NDC?
  • General NDC & GDS Differences
• NDC in the JSON APIs 
  • Prerequisites
  • Requesting and Identifying NDC Offers in the JSON APIs
  • General Support
  • Participating Carriers
  • NDC for Apollo and Worldspan
  • Passive Booking Record
  • Filed Fares
  • MIR (Machineable Interface Record)
• NDC Carrier-Specific Differences
• NDC Support by Country
• NDC and GDS Functionality Comparison Chart
  • General
  • Search
  • AirPrice
  • Ancillaries and EMDs
  • Seats
  • Standalone Fare Rules
  • AirReservation
  • Remarks & Service Requests
  • AirTicketing
  • Air Modify and Exchanges

NDC Basic Concepts

NDC (New Distribution Capability) is a travel industry standard for the distribution and retailing of flight content. NDC is not a system, database, or piece of software - it is a standard for exchanging data.

What is NDC?

The Travelport JSON Air APIs support both NDC and GDS content, or simply NDC and GDS. These terms refer to the content distribution method:

• GDS stands for Global Distribution System. A GDS aggregates and distributes air, hotel, and car rental content such as schedules, fares, and upsells A fare presented along with the base fare as a higher level of service, usually a branded fare. Returned if filed by the carrier and requested with maxNumberOfUpsellsToReturn in the Search request.. Travelport owns the Galileo, Worldspan, and Apollo GDSs, which are also known by the IATA International Air Transportation Association, an organization that standardizes rules, regulations and fare construction principles for the international travel industry. abbreviations 1G, 1P, and 1V.

• NDC is for New Distribution Capability, a program launched by the International Air Transport Association (IATA), the trade association for the world's airlines, to facilitate content distribution directly from airlines to online travel agencies. NDC is an XML standard for exchanging data, and is intended to replace the EDIFACT protocol that has been used by Global Distribution Systems (GDS). NDC distributes content directly from airlines to online travel agencies, GDSs, and travel management companies. NDC content is provided and fulfilled directly by the airline, and may include differentiated content available only through the airlines' direct channels.

Although most JSON API workflows, requests, and responses are the same for both GDS and NDC, airline-specific processes do create some differences. Some functionality is supported only for NDC, or only for GDS, as detailed later in this guide. Because NDC is available only to provisioned customers, this online help has a separate NDC top-level menu to group information and processes that apply only to NDC.

Content for both NDC and GDS in the JSON APIs is sourced from the Galileo GDS (Global Distribution System) for most customers. NDC content from the Apollo and Worldspan GDSs is available to specifically provisioned customers. See the NDC Guide for Apollo and Worldspan.

General NDC & GDS Differences

• NDC is a shopping-led workflow so there is no availability data. Inventory and price are not guaranteed until the booking A confirmed reservation with the carrier. A held booking is a reservation that has not yet been ticketed. The terms booking and reservation are interchangeable. is fulfilled.
• In NDC the airline controls all data available, including offers, booking, storing, servicing, fulfillment, and ticketing.
• Involuntary changes are sent using order change notifications and don’t use the AIRIMP codes HK/TK. (To accept an involuntary change in the JSON APIs, see Accept Involuntary Schedule Change in the Workbench Commit API Reference.)
• NDC generally allows 20 to 30 minutes to create a booking (the offer In the JSON Search APIs, an offer is a product available at a specific price under a set of terms and conditions. An offer includes the flight or connecting flights for one leg of the itinerary, plus a service level that includes the cabin class and any fare codes that may apply. At booking, the selected offer from the Search response - including the flight/s, service level, price, terms and conditions, and brand if applicable - is converted into a single Offer object that is subsequently returned for that booking. time limit). That time limit varies by airline and is returned in the Search response in ReferenceList/TermsAndConditions/ExpiryDate.
• NDC and GDS ticket time limits are the same; a booking will expire if ticketing doesn't take place within a certain time, usually within 24 hours of booking. NDC airlines do not generally return ticket time limit data.
• NDC has two ticketing models: Issuing the ticket on the airline's own stock or using third-party FLX stock.

NDC in the JSON APIs

In general, the JSON APIs handle NDC and GDS content in the same way. Most workflows, requests, and responses across the JSON APIs work the same for both GDS and NDC content, with minor differences noted in the help where applicable.

The exception is that changes to a booked air itinerary The entire trip on a booking, including all flights on all legs. Also called a journey., including voids, exchanges, and refunds, are handled by separate JSON APIs and follow different workflows. This results from differences in how NDC carriers implement these processes.

The NDC menu at the top of every page groups these NDC-specific APIs. Otherwise, all Guides and API References apply to both NDC and GDS.

Prerequisites

To access NDC content you must be provisioned for NDC with Travelport and registered with the NDC airline. Validation occurs at these levels when a request for NDC content via any JSON API is received:

• Validation that the requester is provisioned for NDC within Travelport.
• Request details are sent to the airline system. Airline validates that the requester is registered with them for NDC content.
• Aggregated NDC and GDS content is returned as requested.

Identifying GDS/NDC Offers in the JSON APIs

The JSON APIs identify each offer as either GDS or NDC by returning the value GDS or NDC in the ContentSource object. The examples below show ContentSource as returned in the Reservation Retrieve response. ContentSource is returned in all reservation and ticketing APIs that return the offer on the booking. An upcoming release will add support for returning ContentSource in the Search and AirPrice API responses.

Although Offer/ContentSource provides the simplest way to identify GDS/NDC content, note that Offer/Identifier/authority returns the carrier code for NDC while the value Travelport is returned for GDS.

To request NDC content, in the initial search request, send contentSourceList with either only the value NDC, or both values NDC and GDS. If contentSourceList is not sent, only GDS content is returned.

General Support

The following table outlines broad areas of support in the JSON APIs. More details are provided in the following sections.

NDC Item	Supported in the JSON APIs
IATA NDC schemas	17.2, 18.1, and 18.2
Itineraries supported	Single airline on a booking, multiple passengers
Payment	Generally cash, credit card, and banked funds; varies by carrier
Settlement	ARC and BSP
Travelport booking file	Passive segment A flight or flights under one flight number. One flight equals one segment. A segment could have multiple flights if the flight number remains the same, which happens if a flight makes a stop without changing planes. (ZK)
Mid and back office	MIR/TAIR (DI lines)

Participating Carriers

The JSON APIs have been certified to provide NDC content from the following carriers:

• Qantas (QF)
• United Airlines (UA)
• American Airlines (AA)
• Singapore Airlines (SQ)
• Air France (AF)
• KLM (KL)
• Lufthansa Group (LHG), includes the carriers Lufthansa (LH), Austrian (OS), Brussels (SN), and Swiss (LX)
• British Airways (BA)
• Qatar Airways (QR)
• Iberia Air Lines (IB)
• avianca (AV), includes the carriers Avianca Ecuador (2K), Avianca Costa Rica (LR), Avianca El Salvador and Avianca Guatemala (TA)
• Emirates (EK)
• Malaysia Airlines (MH)
• Scandinavian Airlines System/SAS (SK)
• Malaysia Airlines (MH)
  
• FinnAir (AY)
• Air India (AI)

NDC for Apollo and Worldspan

Content for both NDC and GDS in the JSON APIs is sourced from the Galileo GDS (Global Distribution System) for most customers. NDC content from the Apollo and Worldspan GDSs is available to specifically provisioned customers. See the NDC Guide for Apollo and Worldspan.

Passive Booking Record (PNR)

In the traditional GDS distribution channel, Travelport issues the ticket using the GDS ticketing system, while for NDC the airline itself issues the ticket and handles payment and any subsequent changes. Because the NDC carrier maintains its own booking record (also called a PNR Passenger Name Record. Unique six-digit alphanumeric number that identifies a booking, e.g. JS7GH4. Sometimes used to refer to the booking record itself. Because the term PNR is specific to GDS, this online help uses the more generic term "reservation locator".), Travelport maintains on its host system a passive booking record or passive PNR. This passive PNR generally mirrors the carrier PNR and allows the JSON APIs to return and store information about the booking. At applicable points in the booking workflow, the JSON APIs synchronize this passive booking record with the carrier's booking record.

A successful booking returns a unique six-digit alphanumeric number called the reservation locator Unique six-character alphanumeric code returned for a successful booking, e.g. JS7GH4. For NDC the airline returns an additional locator code, which can be called the vendor locator code. Sometimes called a PNR and used to refer to the booking record as a whole, but because the term PNR is specific to GDS, this online help uses the more generic terms "booking" for the booking record and "reservation locator" for the six-character code. in Receipt/Confirmation/Locator. One instance of Receipt contains the passive record locator for Travelport's passive PNR, returning the locator code itself in Locator/value and a value of either 1G, 1P, or 1V in Locator/source. Another instance of Receipt contains the NDC airline booking reservation locator. This instance returns a carrier code in Locator/source, such as UA or AA, and a different unique code in Locator/value. When sending the record locator in subsequent requests, such as a reservation retrieve, be sure to send the Travelport reservation locator, aka passive PNR code.

The following example shows the Receipt object for a held NDC booking. NDC locators are returned with the carrier code as the source value. In this example, the NDC record locator is returned in the first instance of Receipt/@type ReceiptConfirmation/Confirmation/Locator, with a source value of AA. The Travelport locator, or passive PNR, is returned in the second instance of Receipt/@type ReceiptConfirmation/Confirmation/Locator, with a source value of 1G.

Filed Fares

AirReservation applies the following handling to filed fares in the passive PNR:

• Updates handling of filed fare details so that if the price changes between the time of booking and ticketing, the passive booking record reflects the updated price at ticketing.

• Updates handling of filed fare details so that if there is any change in the itinerary (date change, time change, routing change, etc.) and the airline exchanges the original ticket for a new ticket, the filed fare for the original ticket is canceled and replaced with the filed fare for the exchanged ticket. This ensures the exchange Cancel or modify a ticketed itinerary and issue a new ticket. See the Cancel, Exchange, and Refund Options Guide. is handed and reported per ARC/BSP standards and that the same information is sent to the MIR (management information report) and the back office system. (In the BSP market, when the original ticket is exchanged for a new ticket, the fare is collected either as a NO ADC or an ADC. In the ARC(US) market, the fare is created with the total values which includes base fare, taxes and total fare.)

MIR (Machineable Interface Record)

AirReservation supports generating a MIR (machineable interface record) for ticket issuance, ticket exchanges, and ticket voids for NDC in the same format as for GDS ticket issuance, exchange, and void Voiding a ticket cancels the ticket and payment and is based on rules for the market in which the ticket was issued. Generally a ticket can be voided only the same day it was issued, usually up to midnight local agency time. See the Exchange, Refund, and Void Guide.. This ensures consistent mid- and back-office reporting and handling for NDC as well as GDS itineraries.

NDC Carrier-Specific Differences

The notes below provide basic carrier differences from general support, ordered alphabetically by carrier full name. 

For a complete list of carrier-specific differences, see the Travelport Knowledge Base article linked for each carrier below.

Knowledge Base NDC Resources

Where applicable, this online help lists differences between support for GDS and NDC content in the JSON APIs. Within NDC, however, individual NDC carriers differ in their support for various functionality. The following Travelport Knowledge Base article lists carrier support for functionality and provides links to carrier-specific pages:

KB0040467: NDC capabilities by airline through JSON API

You must be logged into the customer portal to view articles. If the link above does not work, or you are not logged in:

1. Log into https://my.travelport.com.

2. In the Help and Resources menu at the top of the page, select Knowledge base.

3. Enter either NDC Capabilities by airline or KB0040467 in the search bar at the top of the page.

If you do not have a Travelport customer login, please contact your Travelport representative.

Air France/KLM (AF)

Booking ancillaries or seats is not supported for AF/KLM.

In an exchange or modification, the Reshop request supports does not support any search modifiers for AF/KLM.

Some private fare Special air fares negotiated by agencies. Private fares may use account names, account codes, contract codes, or corporate IDs. support must be requested using special PTCs (passenger type codes):

• For VFR (visit friends and relatives) Private Fares, the fare request in the UK market must use PTC Passenger Type Code, used to categorize travelers. The most common PTCs are adult (ADT), child (CNN), and infant (INF). You can request a maximum of 9 passengers in one Search request. JCB (ADT), JNN (CHD), or JNF (INF).

• For Tour Operators, the supported passenger types are IIT, INN, and ITF.

American Airlines (AA)

In an exchange or modification, the Reshop request supports only the cabin class and fare type search modifiers for AA.

Applying an unused ticket as FOP is supported only on AA NDC.

For Ancillary EMDs:

• For carbon offset ancillary Any paid optional service filed for a flight. Industry examples include paid seats, paid baggage, carbon offsets, pet transport fees, and unaccompanied minor charges. See the Ancillary and EMD Guide for supported ancillaries., payment is optional; can book and hold or pay at booking.

• A carbon offset ancillary can be added to a held booking, but not a ticketed booking.

• AA does not issue an EMD Electronic miscellaneous document (EMD); issued for a paid seat, ancillary, or any other paid service after successful payment. See the Ancillary and EMD Guide. for a carbon offset ancillary. A confirmation email is generated from an external service vendor.

• The carbon offset ancillary is charged for all passengers/segments in the booking. Applies to full itinerary.

avianca (AV)

Booking ancillaries is not supported for avianca.

AV supports the following PTCs: ADT, CHD, CNN, INF, INS, SRC and STR (STR is available only in Columbian markets ADZ and LET using a Columbian PCC Pseudo city code. A travel provider's identification code for the JSON APIs, provisioned from Travelport. Used to determine access and other settings in the JSON APIs for your company.).

All other feature functionality and business rules matches Singapore (SQ) per below.

British Airways (BA)

Booking ancillaries is not supported for BA.

BA does not guarantee the price of a held booking. When ticketing a held booking, if the price has changed, the JSON APIs return the error message ERROR AT ISSUANCE TIME: TST EXPIRED - OVERRIDE OR DELETE AND REPRICE Code = \"376\". In this case, you must use the Reprice and Resell APIs (see the Exchange, Refund, and Void Guide) and send payment to complete ticketing.

BA requires a billing address for credit card form of payment.

BA does not support a modification that adds new air segments.

In an exchange or modification, the Reshop request supports does not support any search modifiers for BA.

BA does not support adding a known traveler number to an existing reservation, only in the Add Traveler step of the initial booking workflow.

Emirates (EK)

Booking ancillaries or seats is supported for Emirates only for an existing reservation, not in the initial booking workflow.

Exchanges:

• Up to three ticket exchanges allowed.

• Payment is not required when making changes t the air itinerary (book and hold supported).

Iberia Air Lines (IB)

IB supports only ADT, CHD, and INF passenger types.

IB supports the Spanish Residency and Large Family discounts requested in TravelerGeographicLocation per the Search API Reference.

Iberia requires payment when booking paid seats or ancillaries; only the Instant Pay booking workflow is supported, not book and hold.

Lufthansa Group (LHG)

Booking ancillaries is not supported for LHG. Booking seats is supported only for an existing reservation, not during the initial booking workflow.

In an exchange or modification, the Reshop request supports does not support any search modifiers for LHG.

Malaysia Airlines (MH)

Booking ancillaries is not supported for MH.

MH supports ADT, CHD, CNN, INF, INS, SRC passenger types.

MH does not support open-jaw Itinerary where the departure city is not the same as the return city, or the arrival city is not the same as the return departure city; e.g., LHR > CDG and AMS > LHR. searches; only one-way An itinerary with a single destination; e.g., LHR > CDG., round-trip An itinerary in which travel goes to a single destination and returns to the origin. E.g., LHR > CDG and CDG > LHR. and connecting multi-city An itinerary that includes multiple destinations; e.g., LHR > CDG > AMS > BCN. flights.

All other feature functionality and business rules matches Singapore (SQ) per below.

Qantas (QF)

When running a multiple passenger search, Qantas supports only these PTCs: ADT, CHD, CNN, INF. Sending any other PTC may result in an error at ticketing.

Qantas supports only one account code. If multiple codes are sent, only the first code is processed.

In an exchange or modification, the Reshop request supports only the cabin class and fare type search modifiers for QF.

The Cancel Payment API to void an NDC ticket and payment but retain segments is supported only for QF.

Qatar Airways (QR)

Booking ancillaries or seats is not supported for Qatar.

QR supports only ADT, CHD, and INF passenger types.

QR does not allow changes to passenger information.

QR does not allow search modifiers other than cabin class.

QR does not return brand An upgrade from the base fare that includes certain features in the price, such as wifi or seat selection. Features included in a brand are specified in the brand attributes (BrandAttributes object). information.

QR does not support special service requests.

Exchanges:

• Payment required when making changes to a ticketed booking. You cannot hold the modified itinerary.

• Does not support modification of connecting flights.

• Only one ticket exchange is allowed.

SAS (SK)

SAS is an abbreviation of the company’s full name, Scandinavian Airlines System.

Booking ancillaries is not supported for SK.

SK supports only cash as form of payment.

SK supports ADT, CHD, YTH, INF, SEA, ITX, LBR passenger types.

All other feature functionality and business rules matches Singapore (SQ) per below.

Singapore Airlines (SQ)

Singapore Airlines returns tax codes but not tax descriptions in responses.

OB fees are added to the total fare only if a credit card BIN number is provided in the AirPrice request. If this is not done, and a credit card is then used to ticket the booking which had been held without an FOP or with a FOP different from the one subsequently used to ticket, then ticketing will fail due to price mismatch. Support will be added in a future release to support this workflow and ensure the ticketing does not fail.

Singapore Airlines charges OB fees when a credit card is used as a Form of Payment in the following point-of-sale countries: United Kingdom, Netherlands, Australia, New Zealand, and Belgium. For these countries, OB fees are charged when provided with BIN number at the time of Price. OB fees are added to the offer price when the booking is created.

Ancillary EMDs: For paid baggage only, must book and hold first, then pay later. For other ancillaries, payment can be made in the initial ancillary booking session or in a subsequent session.

In an exchange or modification, the Reshop request supports only the cabin class search modifier for SQ.

United Airlines (UA)

UA returns baggage text in TermsAndConditionsAir/BaggageAllowance/BaggageItem.

Ancillary EMDs: Payment must be included in the ancillary booking session for all ancillaries; hold and pay later is not supported.

In an exchange or modification, the Reshop request supports only the cabin class and fare type search modifiers for UA.

NDC Support by Country

NDC carrier content is available for booking through the JSON APIs in the countries listed below. Where NDC content is available, your Travelport account manager will ensure you have been enabled for the content. You may also need to register directly with the airline to gain access to the NDC content.

NDC and GDS Functionality Comparison Chart

As the NDC technology continues to develop, the JSON APIs handle certain functionality differently between NDC and GDS:

• Ticketing: In the GDS distribution channel, Travelport issues the ticket. For NDC, the airline itself issues the ticket and handles payment and any subsequent changes. The general JSON API booking workflow is the same for both GDS and NDC in the JSON APIs.

• Changes to a booking: After booking, however, GDS and NDC use separate APIs and workflows for voids, exchanges, refunds, and certain modifications. This results from differences in how these processes are implemented by the NDC carriers.

• Payment: Payment processes can differ between GDS and NDC, and for individual NDC carriers.

The NDC menu at the top of every page in this online help groups the NDC-only topics. Otherwise, all topics in this online help apply to both NDC and GDS with differences noted where applicable.

The following table outlines the functionality differences between NDC and GDS in the JSON APIs.