GDS still moves a large share of hotel bookings, but not the way it did twenty years ago. In this post, we break down what Amadeus, Sabre, and Travelport actually return for a hotel search in 2026, where each one still wins, and where a modern hotel API stack replaces them outright. If you are choosing between GDS, a bedbank API, and an aggregator, this is the practical version of that decision.

“GDS is not going away. But it is no longer the default for hotel distribution, and buyers should stop treating it like one.”

What GDS actually is in 2026

A Global Distribution System, or GDS, is a network that connects travel sellers (agencies, TMCs, some OTAs) to airline, car rental, and hotel inventory through a single connection. The three that matter today are Amadeus, Sabre, and Travelport. Every other GDS from the 1990s and 2000s (Worldspan, Galileo, System One) has been absorbed into one of these three.

The airline side of GDS is still dominant for corporate travel. The hotel side is smaller than most people assume and has changed shape completely. A GDS today is not a warehouse of hotel content. It is a routing layer that pulls hotel rates and availability from two very different sources and presents them through one query interface:

• Direct GDS-loaded chain inventory, where large hotel brands push rates straight into Amadeus, Sabre, or Travelport the way airlines push fares.
• Aggregated third-party content, where the GDS resells inventory it sources from bedbanks and wholesalers, then displays it inside the same search results as native GDS content.

That second category is the part most buyers do not realize exists. When a travel agent searches a city in Sabre and sees 8,000 properties, a large share of that count is not Sabre’s own hotel relationships. It is aggregator content licensed and re-displayed inside the GDS shell. We cover how this differs from a true bedbank API connection later in this post.

If you are new to how hotel connectivity works generally, our guide on what hotel APIs are and how they power booking platforms is a useful starting point before this one.

The three surviving GDS players: what each one returns for hotels

Amadeus, Sabre, and Travelport are not interchangeable, even though sales teams from all three describe their hotel coverage in nearly identical language. The differences show up once you look at the actual response payload, not the marketing page.

Amadeus

Amadeus runs the deepest content model of the three. Its Hotel Content service returns detailed descriptive fields (property attributes, guest room descriptions, meeting space, restaurant hours, imagery, points of interest) because Amadeus built a full content management layer for hotel chains to publish directly into. Amadeus also runs Amadeus Value Hotels, a net-rate program that blends wholesale inventory into the same search response as GDS-native chain rates. See our Amadeus integration hub for connection specifics, and our XML API integrations catalog if your stack still runs on XML rather than JSON.

Sabre

Sabre has pushed hardest to blend GDS and aggregator content into one shopping experience. Its Content Services for Lodging product explicitly lets an agency “shop GDS and aggregator content in a single view,” and its booking API distinguishes internally between a “CSL” (aggregator-sourced) hotel segment and a legacy GDS segment, a distinction most travel agents never see on screen. Sabre’s descriptive content response covers hotel name, chain, attributes, amenities, policy, location, and images, a solid but narrower field set than Amadeus. Full details are on our Sabre integration hub.

Travelport

Travelport’s Stays API (formerly the Hotel v11 JSON APIs) gives access to roughly 140,000 properties, with around 100,000 of those shared with major OTAs because the underlying content includes aggregated inventory such as Booking.com. Travelport’s newer SearchComplete endpoint collapses search, availability, and property detail into one call, which is a real engineering improvement over the three-call pattern GDS integrations used to require. Property descriptions, amenities, and images are included, but detail depth still depends on what the underlying supplier provides. See the Travelport integration hub for connection notes.

The practical takeaway on Amadeus vs Sabre vs Travelport: Amadeus wins on content depth for branded chain properties, Sabre wins on blended GDS-plus-aggregator shopping, and Travelport wins on raw property count and a newer, simpler API shape. None of the three wins on independent, leisure-focused, boutique inventory. That is not what they were built for.

What a GDS returns vs. a bedbank API vs. a direct connect

This is the section that actually decides which stack a buyer should use, so we will be specific rather than diplomatic.

A GDS response for a hotel search returns:

• Availability and rate for the specific property and dates queried, sourced either from the chain’s own GDS feed or from a blended aggregator feed the GDS has licensed.
• Descriptive content that ranges from strong (Amadeus, for chain-published properties) to thin (any GDS, for independents that never bothered to fill in their content sections).
• A booking confirmation tied to a PNR-style locator, built for agency workflows: change requests, ticketing remarks, corporate travel policy fields, loyalty program numbers.
• Commissionable rates in most cases, because the GDS commercial model was built around agency commission, not net-rate margin stacking.

A bedbank API, by contrast, returns:

• Net rates the OTA or reseller marks up itself, which is why bedbanks like Hotelbeds (800K+ properties), WebBeds (500K+ properties), and TBO Holidays (1M+ properties) dominate leisure OTA supply stacks.
• Static content delivered separately from live rates, so refresh cycles for descriptions and images do not compete with live pricing calls.
• Room-level detail suited to comparison shopping: bed type, view, cancellation window, meal plan, all fields leisure travellers actually filter on.
• Deeper independent and boutique property coverage, because bedbanks contract directly with individual hotels and regional wholesalers rather than relying on chain head-office feeds.

A direct connect (an OTA integrating straight into a hotel chain’s own central reservation system) returns the cleanest, most current data of the three, but only for that one chain, and only if the engineering investment is worth it for the volume that chain drives. Direct connects make sense for the top 10-20 chains an OTA sells heavily and rarely make sense beyond that, since a channel manager API or aggregator layer covers the long tail far more efficiently.

The field-depth gap matters more than most procurement teams budget for. Sabre’s hotel content response covers roughly a dozen structured descriptive fields per property. Amadeus returns closer to four dozen once room, facility, and location detail are included. A typical bedbank’s hotel content API response sits in between, but with far higher fill rates on independent properties because that is the inventory the bedbank actually built its business on.

Where GDS still wins

GDS is not obsolete. It is just narrower than it used to be. It remains the right tool in specific, recurring situations:

• Corporate travel and managed travel programs. Duty of care, negotiated corporate rates, and policy compliance fields are built into GDS booking flows in a way no bedbank API replicates.
• Travel management companies (TMCs). TMC desks run on GDS terminals and agent workflows that took decades to standardize. Ripping that out for an API stack usually costs more than it saves.
• Branded chain inventory at scale. A hotel chain that pushes rates into all three GDS platforms simultaneously gets guaranteed distribution to every agency desk on earth without negotiating hundreds of individual contracts.
• Rate parity and commissionable bookings. Agencies that need commission-based settlement, not net-rate markup, still route through GDS because that is what the commercial model was designed for.
• Air-plus-hotel bundling inside one PNR. When an itinerary needs air, car, and hotel tied to a single record for a corporate traveller, GDS still does this better than stitching together separate APIs.

Where GDS loses

The weaknesses are just as consistent as the strengths:

• Leisure OTAs competing on price. GDS commissionable rates rarely beat bedbank net rates on identical rooms, because the wholesale channel is built to undercut on price, not preserve agency commission.
• Metasearch and comparison shopping. Metasearch needs thousands of rate combinations refreshed every few minutes across a huge property set. GDS response times and content depth were not built for that query pattern at that volume.
• Independent and boutique hotels. Coverage thins out fast once you move past branded chains, because independents were never the GDS’s core customer.
• Content-rich comparison pages. A leisure booking page needs 15-20 photos, granular room amenities, and guest review integration. Thin GDS descriptive content forces OTAs to backfill from a separate hotel content API anyway, which erases most of the “one connection” advantage GDS is supposed to offer.
• Speed of new supply onboarding. Adding a new independent hotel to GDS distribution can take weeks of chain-side content setup. A bedbank can onboard the same property through its own supplier pipeline in days.

When to layer GDS with an aggregator, and when to skip GDS entirely

Most mid-size OTAs and bedbanks are not choosing GDS instead of an API stack. They are deciding whether GDS earns a place inside a stack that already includes bedbanks, direct connects, and an aggregation layer on top.

Layer GDS in when:

• You sell to corporate or managed-travel customers who expect GDS-standard booking and policy workflows.
• You need chain inventory the GDS carries natively and a direct connect to that chain is not commercially justified yet.
• Your customer base includes TMCs that will only book through familiar GDS rails.

Skip GDS entirely when:

• Your business is leisure-first and price-sensitive, where bedbank net rates consistently beat GDS commissionable rates.
• You are building a metasearch or comparison product that needs high refresh rates across large property counts, not agency-style single lookups.
• Your content requirements (photos, room detail, review integration) exceed what any GDS descriptive feed reliably provides.

In both cases, the connection math gets complicated fast once you are running GDS feeds alongside multiple bedbanks and direct connects, because each source names, codes, and describes the same physical hotel differently. That is a hotel mapping problem, not a sourcing problem, and it is worth reading how hotel mapping and room mapping works before you add a fourth or fifth supplier to an existing stack. A hotel API aggregator exists specifically to sit between all these sources (GDS, bedbanks, direct connects) and hand your booking engine one clean, de-duplicated property record instead of five conflicting ones.

GDS vs. bedbank API vs. aggregator: a side-by-side comparison

For a broader view of how individual providers stack up outside this three-way comparison, see our comparison of the best hotel API providers and the full supplier integration hub.

Key takeaways

1. GDS in 2026 is a routing layer, not a content warehouse. A large share of what shows up in Amadeus, Sabre, or Travelport search results is licensed aggregator content, not native GDS inventory.
2. Amadeus, Sabre, and Travelport each behave differently: Amadeus leads on content depth, Sabre leads on blended GDS-plus-aggregator shopping, Travelport leads on property count and a simpler modern API shape.
3. GDS still wins for corporate travel, TMCs, and branded chain distribution at scale. It consistently loses on leisure price competitiveness, independent hotel coverage, and content depth for comparison-heavy booking pages.
4. A bedbank API and a direct connect solve different problems than GDS. Bedbanks win on net-rate pricing and independent coverage; direct connects win on freshness for a chain’s own inventory, but only at volume.
5. Running GDS alongside bedbanks and direct connects creates a room and property mapping problem before it creates a sourcing problem. Solve mapping before adding your third or fourth supplier, not after.
6. Most OTAs do not need to choose GDS or a modern API stack. The real decision is whether GDS earns a place inside a stack anchored by bedbanks, direct connects, and an aggregation layer.