Travel Tech APIs: Sabre, Amadeus, Direct Hotel Connections

Travel technology APIs are among the oldest and most ossified in software. The Global Distribution Systems (Sabre, Amadeus, Travelport/Worldspan/Galileo) date to the 1960s and still run on protocols and conventions from that era. Direct supplier connections (hotel chains, airlines) have substantial variation. Modern travel-tech integration requires navigating substantial complexity. This post walks through the pragmatic 2026 patterns.

The GDS landscape in 2026#

The three substantial GDS providers:

Sabre. Substantial market share, particularly in North American agency channels. Sabre Red 360, Sabre APIs.

Amadeus. Substantial market share globally, particularly Europe. Amadeus Travel Platform, Amadeus APIs.

Travelport. Combined Worldspan and Galileo, with substantial agency presence. Travelport+ platform.

Each operates substantially differently; integration with all three is substantial work.

Substantial recent evolution: NDC (New Distribution Capability) — airline-direct distribution standard — is supplanting some GDS use cases. Hotel direct connections are increasingly the substantial way to access hotel inventory.

What GDS APIs actually look like#

GDS APIs reflect their substantial legacy:

Legacy formats. Sabre’s command-line cryptic codes (e.g., “1L100Y15JANJFKLHR”) still surface in API responses. The XML envelopes wrap commands that originated as terminal commands.

Substantial XML. SOAP-style APIs still common; REST adoption recent and partial.

State and session management. Substantial concept of “PNR” (passenger name record) that requires session state to manipulate.

Substantial pricing complexity. Fare rules, fare construction, ticketing rules — substantial business logic embedded in responses.

Substantial error handling. Specific error codes meaning specific things; substantial documentation required.

The integration is substantial work; the documentation is voluminous; the testing is challenging.

NDC (New Distribution Capability)#

NDC is the IATA standard for airline-direct distribution.

The substantial value:

• Airline-direct access without GDS middleman.
• Richer content — ancillaries, fare bundles, plus the various.
• More flexible pricing — dynamic offers.
• Better margins for both airlines and distributors.

The substantial complexity:

• Each airline implements NDC differently. Substantial variation in interpretation.
• Aggregators emerged to manage the variation — Duffel, Verteil, plus the various.
• GDS-NDC integration — GDSes themselves now provide NDC content alongside legacy.

By 2026, NDC adoption is substantial but not universal. Substantial airlines have substantial NDC offerings; some haven’t yet.

Hotel direct connections#

Hotel integration has substantially evolved.

Major patterns:

• Direct connect chains — Marriott (MARSHA), Hilton (OnQ), IHG (Holidex), Hyatt (Reserve), plus the various — provide direct APIs for substantial inventory.
• Hotel channel managers — SiteMinder, Cloudbeds, plus the various — aggregate inventory across smaller properties.
• Aggregators — Hotelbeds, Booking Holdings APIs, Expedia EAN, plus the various — provide aggregated hotel inventory.
• GDS for hotels — substantial but increasingly secondary to direct connections.

The choice of integration approach substantially affects content quality, pricing competitiveness, and operational complexity.

The aggregator approach#

For most modern travel-tech builds, aggregators are the practical entry point.

Air aggregators:

• Duffel — substantial NDC-anchored aggregator with substantial airline coverage.
• Verteil — comparable NDC aggregation.
• Travelfusion — legacy aggregator with substantial deep content.
• GDS APIs themselves as aggregation layer.

Hotel aggregators:

• Hotelbeds — substantial B2B hotel inventory.
• Booking Holdings APIs (Booking.com) — substantial coverage with B2B program.
• Expedia Group EAN — substantial coverage.

Mixed:

• TravelPort with multi-modal coverage.
• TBO Holidays — for some regions.

The aggregator choice depends substantially on geographic focus, content needs, and commercial relationships.

The build-vs-buy decision#

For most companies building travel products in 2026:

Use aggregators for the actual booking integration. The build effort is substantial; the aggregators have done it.

Build the booking flow — your UX, your business logic, your customer relationship.

Build the booking management — post-booking changes, cancellations, customer service.

Integrate payment carefully — travel payment has substantial fraud and chargeback patterns specific to travel.

Plan for caching and aggregation — travel APIs are slow and rate-limited; substantial caching is necessary.

The data quality challenges#

Travel APIs have substantial data quality challenges:

Inconsistent property data. Hotel descriptions, photos, amenities vary substantially across sources.

Pricing freshness. Prices change continuously; cached prices become stale.

Availability accuracy. “Available” in API doesn’t always mean actually bookable.

Substantial data cleaning required. Most travel-tech operations have substantial data engineering work just to normalize content across sources.

Where pdpspectra fits#

Our data engineering and integration practice supports travel-tech operators with API integration, content normalization, and platform engineering.

Related reading: the field service post, the maritime port operations post, and the AI customer service post.

---

Travel-tech integration is substantially complex. Talk to our team about your travel platform.