~/blog/gds-integrations-amadeus-sabre-travel-api
Travel Tech2013·15 September 2013

GDS Integrations: Inside Amadeus, Sabre, and the World of Travel APIs

At Da!Travel, I built integrations with the world's major GDS providers — Amadeus, Sabre, Sirena, and others. The travel industry's data infrastructure is unlike anything else in software. Here's why.

GDSAmadeusSabretravelAPIDa!Travel

The GDS World

If you've never worked in travel technology, the Global Distribution System (GDS) world is alien. These systems — Amadeus, Sabre, Travelport (Galileo/Worldspan) — are the backbone of global flight and hotel inventory distribution. Airlines and hotels load their availability and pricing into GDS systems; travel agents and OTAs (Online Travel Agencies) query them to show and book inventory.

The history is remarkable: Sabre was originally built by American Airlines in the 1960s. These systems predate the internet. They predate relational databases. And they're still the dominant inventory distribution channel for commercial aviation.

At Da!Travel, I led the development of a meta-search engine for flights and hotels. That meant integrating with multiple GDS providers simultaneously and reconciling their different data formats into a coherent user experience.

The IATA/GDS Data Model

The GDS data model is built around IATA standards — the International Air Transport Association defines formats for flight schedules, pricing, booking records (PNRs), and more. Understanding IATA concepts is prerequisite to GDS integration:

PNR (Passenger Name Record): The booking record. Every flight booking has a PNR — a 6-character locator code like "ABCD12". The PNR contains passenger details, itinerary segments, ticketing information, and special service requests.

Fare classes: Airlines segment their seating into booking classes (Y, B, M, K, etc.) each with different pricing rules, restrictions, and availability. A "seat" on a flight isn't a physical seat — it's a combination of origin, destination, dates, and fare class.

Availability vs Pricing: These are separate queries in most GDS systems. First you check availability (are seats bookable on this flight/class?), then you price (what does this combination cost with this fare's rules?). Conflating them is a common beginner mistake.

Meta-Search Caching: The Core Engineering Challenge

A meta-search engine queries multiple GDS sources simultaneously and presents unified results. The fundamental challenge: GDS queries are slow and expensive. A single availability+pricing query to Amadeus might take 2-5 seconds. For a search page showing 50+ options, querying in real-time is impossible.

Our caching strategy:

Pre-computation for popular routes: High-volume routes (London-Dubai, London-New York, etc.) were queried on a schedule and results cached. Users on these routes got near-instant results.

Search result caching with TTL: When a user searches and we query GDS, we cache the results for 15 minutes. Subsequent searches for the same route/date within that window hit the cache. Critical: GDS prices change constantly, so the TTL must be short enough that displayed prices are still purchasable.

Availability vs Price caching separately: Availability (which flights exist) changes slowly. Prices change constantly. We cached them with different TTLs — 4 hours for availability, 10 minutes for prices.

Session state for booking: When a user selects a flight and proceeds to booking, we hold their selected fare in a session. GDS systems have a "fare hold" mechanism for exactly this purpose — but it has an expiry, typically 30 minutes.

The Integration Lessons

Amadeus and Sabre have different APIs, different semantics, and different error handling. Abstracting across them required a well-designed adapter layer — each GDS adapter translated the GDS-specific response into our internal model, shielding the rest of the application from provider details.

Error handling in GDS integrations is particularly important. GDS systems return a taxonomy of error codes — some meaning "try again", some meaning "this fare is no longer available", some meaning "your authentication has expired". A naive integration that treats all errors the same will produce confused users and poor conversion rates.

The travel industry is a masterclass in the complexity of distributed data systems at global scale. I learned more about eventual consistency, caching, and API design in 18 months of travel tech than in the preceding 5 years.