GDS vs NDC vs aggregator APIs: which one does a small travel agency need?

The GDS vs NDC debate used to belong to airlines and very large travel companies. Today it reaches every small agency that wants live fares in its own website or back office, and there is a third option on the table as well: the flight aggregator API.

This guide explains what each of the three is, what it costs you in money, time and paperwork, and which one suits which kind of agency. We run an aggregator-style platform ourselves, so we will be clear about where that model fits and where it does not.

What a GDS is

A global distribution system is a marketplace that sits between airlines and travel sellers. Three of them matter worldwide: Amadeus, Sabre and Travelport. Each collects schedules, published fares and seat availability from its participating airlines, and lets an agent search, book and ticket across all of them from one system.

The GDSs grew out of the computer reservation systems that airlines built for their own staff and later opened to travel agents. That heritage still shows. Classic GDS messaging is based on EDIFACT, a terse electronic data interchange format designed when bandwidth was expensive. Most fares are filed in advance through a fare publisher such as ATPCO, and the GDS builds a price by matching a filed fare with a booking class that still has seats.

Strengths

• Breadth. One connection covers a very large share of full-service airlines, including itineraries that combine several carriers on one ticket.
• Mature servicing. Voids, exchanges, refunds, queues and schedule changes follow established workflows that agents and back-office systems already understand.
• Ecosystem. Mid-office, accounting and corporate booking tools have been built around GDS records for decades.

Costs and requirements

GDS access is a commercial contract, not a sign-up form. Expect to negotiate an agreement, often with booking volume expectations attached, and to pass a certification step before your application may book in production.

To issue tickets yourself you also need ticketing authority. In most markets that means accreditation with the International Air Transport Association (IATA) and participation in its Billing and Settlement Plan, which the association describes as the framework for sales reporting, remittance and settlement between airlines and accredited agents. In the United States the equivalent body is the Airlines Reporting Corporation. Agencies without accreditation typically book in the GDS and ask a consolidator to issue the ticket.

On the technical side, modern GDS web services use XML or JSON, but the data model still reflects the EDIFACT era: PNRs, segments, booking classes, fare bases, queues and ticketing time limits. A developer who is new to travel needs time to learn that vocabulary before writing useful code.

What NDC is, and what it is not

NDC stands for New Distribution Capability. The International Air Transport Association (IATA) describes it as an XML-based data transmission standard built on offer and order management, so that airlines can create and distribute offers regardless of the distribution channel. The same page states that the standard is voluntary and open to third parties.

The important word is standard. NDC is not a system you can log in to. In practice an NDC connection is an API that an airline, or the airline's technology provider, exposes using some version of the NDC message schemas. The airline builds each offer itself at request time and returns it with a price and an offer identifier. When you book, the airline creates an order in its own system.

What NDC changes

• Richer content. Fare families arrive with descriptions, baggage allowances and change conditions inside the offer, instead of codes the agent has to decode.
• Ancillaries. Seats, bags and other extras can be priced and sold in the same flow as the fare.
• Airline-controlled offers. The airline decides the price and the bundle when you ask, which allows fares and bundles that are not filed in the traditional way and may exist only in NDC channels.
• Channel pricing. Some airline groups add a surcharge to tickets issued through traditional GDS channels and do not apply it to their NDC channels. Lufthansa Group's Distribution Cost Charge, introduced in 2015, is the best known example.
• Fragmentation. Every airline implements its own schema version and its own subset of functions. Servicing in particular, meaning changes, refunds and schedule disruptions, differs from one carrier to the next.

That last point is where the GDS vs NDC choice becomes a practical problem for a small agency. A direct NDC connection usually means one commercial agreement, one certification and one integration per airline, and each connection covers only that airline's flights. Many airlines also expect the seller to be accredited or to have a ticketing arrangement in place.

What a flight aggregator API is

A flight aggregator API, sometimes called a consolidator API, puts several content sources behind one integration. The aggregator holds the supplier contracts, connects to GDS content, NDC channels and low-cost carriers as its business requires, and normalises everything to one request and response format. You send one search and receive one list of offers in one JSON shape, whatever the origin of each offer.

Because the aggregator or its ticketing partner holds the ticketing authority, you usually do not need accreditation of your own. You book through them and the ticket is issued under their authority. We cover that model in how to sell flights without IATA accreditation, and if the term itself is new to you, start with what a flight API is.

The trade-offs are real. You depend on the coverage the aggregator has contracted, on its fee or markup, and on its servicing process. You will not see a private fare that an airline might have negotiated with you directly. For a small agency that is rarely a problem. For a large one with its own airline deals it is a good reason to go direct.

GDS vs NDC vs aggregator API: comparison by criterion

Access requirements

• GDS: a signed commercial agreement, certification of your application, and accreditation or a consolidator if you want tickets issued.
• Direct NDC: approval by each airline, usually an agreement per carrier, often an accredited or otherwise recognised seller.
• Aggregator: an account with the aggregator and whatever checks it runs. Usually no accreditation.

Time to integrate

• GDS: the longest of the three, because of contracting, the learning curve of the data model and certification.
• Direct NDC: moderate for the first airline, then repeated for every additional airline.
• Aggregator: the shortest. One REST and JSON integration, one set of documentation.

Content

• GDS: very broad full-service coverage and multi-carrier itineraries. Some airline offers and ancillaries may be missing or surcharged.
• Direct NDC: the airline's fullest content, including bundles and ancillaries, for that airline only.
• Aggregator: a blend chosen by the aggregator. Wide enough for most leisure and small business demand, but defined by its contracts, not yours.

Cost model

• GDS: contract terms that vary by agency and volume, plus the fixed cost of accreditation and financial guarantees if you ticket yourself.
• Direct NDC: development and maintenance cost per airline. The fare itself can be cheaper where an airline surcharges other channels.
• Aggregator: a fee or markup per booking, a subscription plan, or both. Little or no fixed cost before the first sale.

Servicing

• GDS: the most complete and consistent tooling for changes and refunds.
• Direct NDC: depends on the airline. Some operations may still require a call or a portal.
• Aggregator: handled through the aggregator, by API where supported and by its support team where not.

Who holds the ticketing authority

• GDS: you, if accredited. Otherwise the consolidator that issues for you.
• Direct NDC: the airline creates the order, and you sell under your agreement with that airline.
• Aggregator: the aggregator or its ticketing partner. You remain responsible for your customer and for applying the fare rules correctly.

Which one fits your agency: a decision guide

• New or small agency without accreditation: start with an aggregator. You can sell from the first day without financial guarantees or a GDS contract.
• Startup or developer building a travel product: an aggregator API. Your scarce resource is engineering time, and one normalised format protects it.
• Accredited agency already working in a GDS: keep the GDS for servicing and complex itineraries, and add an aggregator or NDC source where the GDS content is weak or surcharged.
• Agency with heavy volume on a few airlines: ask those airlines about direct NDC. The saving per ticket and the richer offers can justify one integration per carrier.
• Large online agency or travel management company: all three, with your own logic deciding which source answers each search.

How the three combine in practice

The choice is rarely either-or. The GDSs now distribute NDC content next to their traditional content. Sabre, for example, advertises the ability to compare NDC, EDIFACT and low-cost carrier content in a single search. Aggregators in turn source from GDSs, from NDC connections and from low-cost carrier APIs.

So the real question behind GDS vs NDC is not which technology wins. It is who does the contracting, integration and ticketing work: you, or an intermediary. A small agency normally starts with the intermediary doing almost all of it, and takes more in-house only when volume justifies the fixed cost.

A sensible path looks like this:

1. Start with an aggregator to prove that your customers will book flights with you.
2. Measure which airlines and routes make up most of your sales.
3. When one carrier becomes a meaningful share, ask it about an agency agreement or a direct NDC connection.
4. Consider accreditation and a GDS contract when the margin you give away to intermediaries is larger than the fixed cost of doing it yourself.

Where IATA.co sits

IATA.co is an aggregator-style platform: a booking portal and a flights API built to put several suppliers behind one format. We are an independent company, not affiliated with the International Air Transport Association, and using our platform does not make you an accredited agent. You book through us, so you do not need your own accreditation, and you stay responsible for your customers and for the fare rules of what you sell.

The commercial model is prepaid. You create a free account, verify your email and top up a balance. Each booking is deducted from that balance, there is no credit line, and every movement appears in a ledger. The portal covers one-way and round-trip searches in economy, premium economy, business and first, for adults, children and infants, and every booking is saved in your dashboard.

For developers, the flights API is REST and JSON. Access is requested from the dashboard and approved by a person, after which you receive an API key and the documentation. Keys work only from whitelisted server IP addresses, each plan sets monthly searches and requests per minute, and responses carry rate-limit headers. Identical searches within a short window are answered from cache, while price and availability are always re-checked with the supplier before a booking is confirmed.

Our flight search API integration guide walks through the search and booking flow, and the article on rate limits, caching and IP whitelisting covers the operational side.

Try the aggregator route first Create a free account to search and book flights in the portal with a prepaid balance. When you are ready to build, request API access from your dashboard and we will review it.