Conventional Airline APIs and NDC APIs: What Travel Sellers Should Know

Conventional Airline APIs vs NDC APIs: What Travel Sellers Should Know

Airline content reaches travel sellers through several sources, including Global Distribution Systems, direct airline connections, consolidators, low-cost airline APIs and New Distribution Capability, or NDC, connections.

These sources can all support flight shopping and booking, but they do not necessarily follow the same distribution model or provide identical content and servicing functionality.

Our earlier guide explains the foundations of NDC. This article focuses on how NDC APIs differ from conventional airline distribution interfaces and what those differences mean for travel sellers.

What is a conventional airline API?

“Conventional airline API” is a broad term rather than a single technical standard. It may refer to an interface provided by a GDS, airline host system, passenger service system, consolidator or another authorised content provider.

Traditional GDS distribution has historically relied heavily on EDIFACT—Electronic Data Interchange for Administration, Commerce and Transport—for structured communication between distribution platforms and airline systems.

However, a modern GDS API presented to a travel seller may use XML, JSON, SOAP or REST while the provider manages the underlying EDIFACT or airline host-system communication.

Conventional airline distribution commonly uses established concepts such as:

• Schedules and availability
• Booking classes
• Filed fares and fare rules
• Passenger Name Records
• Electronic tickets
• Electronic Miscellaneous Documents
• Exchanges, voids and refunds

The functionality available depends on the provider, airline, market and commercial agreement.

The principal difference: fares and bookings versus Offers and Orders

Many conventional GDS workflows are organised around schedules, availability, booking classes, fares, PNRs and tickets.

NDC introduces a retailing model based on Offers and Orders.

An Offer represents flight products and services returned by an airline in response to a shopping request. It may contain the itinerary, price, conditions, baggage entitlement and eligible ancillary services.

When the customer accepts an offer, an Order records the selected products and services.

This structure can give airlines greater control over how their products are assembled and presented. Nevertheless, an airline’s underlying reservation system may continue to create PNRs, tickets and other fulfilment records behind an NDC order.

Content and product presentation

Conventional APIs typically provide the essential information required to compare flights by schedule, availability, cabin, booking class and price.

Depending on the provider, they may also include:

• Branded fares
• Baggage information
• Seat maps
• Ancillary services
• Fare attributes
• Ticketing information

NDC is designed to help airlines communicate more detailed product information through participating distribution channels. An NDC offer may include branded fare attributes, baggage allowance, paid seats, ancillary products, bundles and other airline-defined content.

The actual difference must be evaluated for each connection. Conventional distribution should not be assumed to contain only basic fares, and an NDC connection should not be assumed to include every airline product.

Shopping and pricing

In a conventional GDS workflow, the distribution provider may combine schedules, availability and fare data to produce flight options. Pricing can take place during or after availability shopping.

In an NDC workflow, the airline or its authorised provider returns airline-generated offers based on the shopping request.

NDC offers commonly have identifiers and expiry periods. A selected offer may need to be confirmed or repriced before an order is created.

Price and availability can change in either model. A conventional fare may require validation, while an NDC offer may expire or be withdrawn.

Applications using either approach should:

• Store the relevant offer or pricing references
• Validate the selected option before booking
• Monitor applicable expiry periods
• Communicate material changes to the customer
• Avoid creating a booking without appropriate confirmation

Ancillary services

Ancillary services can include baggage, seats, meals, priority services and lounge access.

Conventional APIs may support these products through separate service requests, seat-map functions or provider-specific processes. Fulfilment may require an Electronic Miscellaneous Document or another airline record.

NDC is designed to integrate eligible ancillary services more closely with the airline’s Offer and Order workflow.

Travel sellers should confirm the actual level of support. A service shown in a response may not necessarily be available throughout the transaction lifecycle.

The seller should establish whether the service can be:

• Displayed
• Priced
• Added to an order
• Paid for
• Fulfilled
• Changed or refunded

Booking and servicing

Conventional distribution commonly uses the PNR as the primary booking record, with electronic tickets and other documents representing fulfilment.

NDC uses offer and order identifiers, although the airline may continue to maintain traditional booking and ticketing records internally.

Travel sellers should retain every relevant reference returned during the transaction, including order identifiers, airline references, PNR locators, ticket numbers and ancillary fulfilment references.

Post-booking servicing is particularly important. Mature conventional interfaces may support booking retrieval, ticket voiding, itinerary changes, reissue, cancellation and refunds.

NDC can also support order retrieval, service additions, changes, cancellation and refunds. However, the available operations vary significantly between airlines.

An NDC connection that supports shopping and order creation may not provide every required servicing function. Travel sellers should verify:

• Whether an order can be retrieved
• Whether seats or baggage can be added later
• Whether itinerary changes are supported
• Whether cancellations and refunds can be initiated
• Whether partially used bookings can be serviced
• Which cases require offline support

Standardisation does not remove airline differences

NDC provides a common message standard, but it does not make every airline implementation identical.

Differences can result from:

• Airline business rules
• NDC schema versions
• Mandatory and optional fields
• Supported markets
• Commercial agreements
• Forms of payment
• Offer-expiry rules
• Servicing capabilities
• Error and warning responses
• Airline host-system limitations

Conventional interfaces can also vary substantially between providers.

An aggregation or connectivity layer can normalise common information and workflows, but airline-specific details must still be preserved when they affect the offer, booking or service.

Integration and maintenance

The complexity of an airline connection should not be judged only by whether it uses EDIFACT, XML or JSON.

A production integration must also address:

• Authentication and authorisation
• Request and response mapping
• Search performance
• Look-to-book requirements
• Offer or fare validation
• Payment processing
• Duplicate-request prevention
• Booking-state management
• Error recovery
• Order retrieval
• Post-booking servicing
• Logging and monitoring
• Certification and production support

A direct airline NDC connection generally needs to be developed, tested and maintained separately for each airline. Conventional content obtained through a GDS or another provider may offer broader coverage through one interface.

Neither approach is automatically simple. The appropriate option is the one that provides the required content and functionality with manageable implementation and operational effort.

Are NDC fares always lower?

NDC does not guarantee the lowest fare.

Airlines may distribute particular products or offers through NDC, but differences can also result from the point of sale, market, currency, passenger type, corporate agreement, fare conditions, included services and promotional availability.

Travel sellers should compare the complete offer rather than the base fare alone. An offer with a higher price may include baggage, flexibility or services excluded from another option.

Can conventional and NDC content operate together?

Yes. Travel sellers do not necessarily need to choose only one content source.

A practical airline-distribution strategy may combine:

• GDS and established EDIFACT-based distribution
• NDC airline connections
• Direct low-cost airline APIs
• Consolidator or other authorised content

When multiple sources return the same itinerary, the application should identify duplicates and compare price, included services, restrictions and servicing capability before displaying the options.

The customer should receive a consistent experience even when the underlying content comes from different channels.

What should travel sellers evaluate?

Before selecting a connection, travel businesses should consider:

• Airline and market coverage
• Fare and product content
• Branded fares and ancillaries
• Supported forms of payment
• Booking and fulfilment
• Changes, cancellations and refunds
• Technical documentation
• Certification requirements
• Reliability and monitoring
• Production support
• Implementation and maintenance effort

The search response should not be evaluated in isolation. The connection must support the operational journey that follows the booking.

How Pratra supports airline connectivity

Pratra provides airline connectivity technology that helps travel agencies, online travel businesses and travel technology platforms access supported content through a unified integration.

The connectivity layer helps travel sellers work with different airline distribution sources while maintaining more consistent shopping, booking and servicing workflows within their customer-facing applications.

Available airlines, content and functionality remain subject to the individual connection, market, commercial agreement and implementation status.

Choosing according to business requirements

Conventional GDS distribution and NDC APIs should not be presented as opposing technologies where one is always outdated and the other is always complete.

Established distribution can provide broad airline coverage and mature operational workflows. NDC can provide airline-generated offers and a more retail-oriented exchange of product information.

The appropriate strategy may use either approach or combine several sources. The decision should be based on airline coverage, content quality, servicing capability, reliability and the customer experience the travel seller needs to provide.