Global Travel Distribution: The GDS Role, Where Growth Sits, and What Comes Next

A global distribution system (GDS) is still the main indirect pipe between airlines and the companies that sell travel: agencies, corporate booking tools, and many online sellers. It is not the whole industry.

Air, hotels, cars, and rail do not share one network. Low-cost carriers often sit outside the classic GDS. Airlines now publish richer offers through a newer standard, NDC, and also sell on their own websites. Product teams that treat "the GDS" as a single API, or as a layer that is about to disappear, mis-scope the work.

This article is a map of that landscape: what the GDS still owns, who the three incumbents are, which neighbouring layers matter, where growth actually shows up, and how AI sits on those layers without becoming a new network.

The stack, in one pass

Read the market from the airline's inventory outward, not from the booking screen inward.

Layer	What it holds	Typical names
Airline control	Schedules, seats, check-in, the operational record	Passenger service systems: Amadeus Altéa and Nevio, Sabre, Navitaire (low-cost, part of Amadeus)
Offer content	Fares, bundles, ancillaries, the shape of what can be sold	ATPCO and EDIFACT for the legacy fare file; IATA NDC for richer offers; airline retail platforms such as Accelya (Farelogix), Datalex, PROS
GDS	Indirect shopping, booking, ticketing, and servicing for agencies	Amadeus, Sabre, Travelport (Galileo, Apollo, Worldspan)
Regional distribution	A local equivalent where the global three do not set the rules	Travelsky in China
API aggregators	One developer interface over GDS, NDC, and direct content	Duffel, Travelfusion, and smaller NDC connectors
Sellers	Who faces the traveller or the corporate buyer	Airline websites, OTAs, metasearch, travel management companies

Hotels and cars appear inside a GDS contract, but their distribution economics are different. A large share of hotel demand is Booking Holdings and Expedia, plus channel managers, not the air GDS. Rail is another pipe again. A "travel platform" that promises all four from one integration is usually stitching several contracts, not calling one system.

What the GDS still does

The GDS was built so a travel seller could see availability and place a booking without a phone call to the airline. That job is still the core:

• shop many airlines in one session;
• create and change the booking;
• ticket and settle with the agency;
• service the trip when a flight moves.

It is a commercial network with decades of agency workflows, private fares, and mid-office processes around it. Corporate travel still leans on it because policy, duty of care, and changes after ticketing are harder than the first search.

The GDS is not the airline's system of record for the flight itself. That stays in the passenger service system. A product that must rebook, add a bag, or keep a corporate traveller inside policy is integrating distribution and servicing, not "reading a database of flights".

Three systems, not a crowd

Almost all traditional GDS air bookings still run through three companies. Public estimates of exact share disagree, so this map does not pick a percentage. Amadeus describes itself as holding more than half of GDS air bookings. Sabre is the main alternative in North America. Travelport is the smallest of the three by revenue and remains relevant for agencies, including in the UK.

Company	Where it is strongest	What else it is
Amadeus	Europe, and a wide air-distribution footprint	Airline IT, Navitaire for low-cost carriers, hospitality technology. Distribution is only part of the group.
Sabre	North America	Agency distribution plus airline and hospitality IT. Air distribution is a larger share of the company than at Amadeus.
Travelport	Agencies, including UK and independent sellers	Galileo, Apollo, and Worldspan under one private company (Elliott and partners). The seller-facing platform is Travelport+.

A fourth full GDS, with the same agency settlement and global content, has not appeared. New companies show up in the layers beside these three: offer-and-order software for the airline, and APIs for the seller who does not want a classic terminal.

The layers that changed the map

NDC is a content standard

IATA's New Distribution Capability lets an airline sell a richer offer than the old fare file: bundles, ancillaries, prices that are not a static tariff. It does not replace Amadeus, Sabre, or Travelport. All three now aggregate NDC alongside legacy content. Airlines also push the same offers through their own channels and through API aggregators.

Adoption is uneven. Shopping NDC from several airlines inside one corporate booking tool is still a project, not a default. Early-2025 industry research (Skift) still described NDC as a small share of bookings processed through the GDS, even while the standard itself was widely discussed. Treat "we will just switch on NDC" as a content gap to design for, not as a completed migration.

Direct and low-cost sit beside the GDS

Airlines want more passengers on their own site, where the offer, the ancillary, and the payment stay in-house. Some add a fee, or withhold a fare, when the ticket is sold through a GDS. Low-cost carriers often distribute through Navitaire or their own API and appear only partly, or not at all, in a classic GDS search.

A leisure search that looks "complete" in a GDS is often missing the carrier the traveller will actually buy.

Aggregators are a translation layer

Duffel, Travelfusion, and specialist NDC connectors exist so a product team can ship one API instead of three GDS contracts plus a set of airline directs. They are not a new global agency network. They do not remove accreditation, settlement, or the servicing rules of the underlying source. They move the integration problem forward: one contract and one payload shape, with the source of each offer still mattering for changes and refunds.

Airline retail is a different product

Offer-and-order platforms (Accelya with the Farelogix line, Datalex, PROS, and others) sell to the airline, not to the agency. Their job is to build and store the offer the way a retailer would, then hand it to direct channels and to NDC. That layer can sit on top of more than one passenger service system. It competes with the airline-IT side of Amadeus and Sabre more than with the agency screen.

Where growth is, and where it is not

Volume follows air travel. When people fly more, GDS bookings rise with the indirect share of those trips. Amadeus and Sabre have both pointed at distribution growth on the back of traffic, not at a new category of buyer.

The mix inside that volume is what moves:

• more of the interesting fare, the bundle, and the bag lives in NDC or on the airline site;
• corporate programmes stay on the GDS longer than leisure, because servicing and policy are the product;
• hotel and car "growth" in a travel app is usually a second supplier, not a GDS feature flag;
• the engineering spend shows up in normalisation: one shopping response that merges EDIFACT, NDC, and a direct API, then a servicing path that still knows which source owns the order.

Two ideas from older commentary do not describe this market. A private blockchain did not become the way agencies reach airline inventory. And the GDS did not get replaced by a single open API that makes accreditation, payment, and schedule changes someone else's problem.

How AI changes the GDS

AI does not become a fourth GDS. It does not hold seats, ticket, or settle with an agency. It changes who asks for the offer, how the offer is built, and how a disruption is handled. The pipes in the table above stay the source of truth.

Three places matter.

The seller's screen. A corporate traveller, an OTA, or an agency desktop can start from a sentence instead of a form. Amadeus, Sabre, and Travelport are all adding that assist inside the tools agents already use. Travelport, for example, has put new capital into AI on its agent desktop and described the GDS as a layer under AI-driven commerce. The assistant still has to call a shopping API. If the model invents a fare or a seat, nothing downstream will ticket it.

The offer. NDC and airline retail already want a priced bundle, not a row in a fare file. AI is how an airline ranks a bag, a seat, and a fare for this traveller, then how a seller ranks those offers across airlines. That logic lives in the offer layer: the airline, a retail platform, or a merchandising add-on on the GDS. It does not live in the chat transcript.

Servicing. A missed connection or a schedule change is where an assistant looks useful, and where a wrong write is expensive. The assistant can propose the next option that the source actually returned. The change still has to be read from, and written back to, the system that owns the order. A copy of the itinerary in a model, or in a search index, is not a ticket.

What fails if the model is allowed to skip that:

• a fare that was never shopped, so it cannot be ticketed;
• two sessions booking the last seat, because nothing was held;
• a private or corporate fare the model cannot see;
• a refund sent to the wrong merchant, because the channel was guessed.

The build that matches this map is a set of tools, not a chatbot over a cache. Shopping and order calls stay typed. A book uses an offer id the source just priced. A price change or a policy break stops for a person. The same normalisation problem as the rest of this article remains: one answer merged from EDIFACT, NDC, and a direct API, with the source of each slice kept for the servicing path.

That is also where Applied AI development meets the distribution stack: agents and tool calls that must book through a priced offer, not a guessed fare. Workflow around the trip (approvals, expense, disruption notices) sits with AI automation. The model is the interface. The web platform and the integration backend still own the order.

What a product team actually builds

If the conversation is the product, the GDS is a supplier. The software around it is usually some of the following:

• an assistant that only offers what a shopping call just returned, and that books with an offer id from that source;
• search that can show a legacy fare and an NDC offer without double-selling the same seat;
• an order model that survives ticketing, a schedule change, and a partial refund;
• ancillaries that are not a free-text remark;
• corporate rules (who may book, which card, what to do when the fare is out of policy) kept outside the GDS, because the GDS will not know the company's org chart;
• payments and settlement that match the channel, including when the airline is merchant of record on a direct or NDC offer.

That is integration and domain modelling. It is the same class of work as any system that must stay correct when a partner API is slow, partial, or versioned. Teams that already run custom web platforms and Java integration backends will recognise the shape: one core record you own, several upstreams you do not.

Takeaways

• The GDS is the indirect agency channel. Amadeus, Sabre, and Travelport still carry almost all of it.
• Passenger service systems, NDC, airline websites, and API aggregators are separate layers. A complete trip search crosses more than one.
• NDC changes the offer. It does not retire the GDS, and it is not evenly available in corporate tools.
• AI changes the screen, the ranking of offers, and disruption handling. It does not hold inventory or settle the ticket. A book that did not come from a priced offer id should not be sent.
• Growth in distribution technology is in mixing those sources and servicing the booking afterwards, not in standing up another global network.
• Hotel, car, and rail content should be planned as extra suppliers.

If you are scoping a seller, a corporate tool, or an airline-side offer path and need a second view of which layer you actually have to integrate, get in touch.