How GDS Integration Actually Works

Every time I explain what I do, I lose people at "GDS."

"It's like an API for flights," I say. Eyes clear a little. "Except it was built in the 1970s and most of the core protocols haven't changed since then." Eyes cloud over again.

This post is my attempt to explain it properly — for developers who are curious, for founders who've been quoted insane prices by travel tech vendors, and for anyone who's ever wondered why booking flights online still feels weirdly clunky in 2026.

What a GDS actually is

A Global Distribution System is a network that connects travel suppliers (airlines, hotels, car rentals) with travel sellers (OTAs, agents, corporations). The three major ones are:

Amadeus — dominant in Europe, APAC
Sabre — dominant in the Americas
Travelport (Galileo/Worldspan) — global coverage, popular with corporate travel

Airlines publish their fares and inventory into the GDS. OTAs and travel agents search and book from the GDS. The GDS takes a booking fee from the airline. Simplified, but that's the core.

The part that breaks developers' brains: these systems were built for travel agents using terminal interfaces, not REST APIs. Amadeus's native protocol is called Amadeus Script, which looks like COBOL had a bad dream. Sabre uses a format called TPF (Transaction Processing Facility), designed for IBM mainframes.

The three ways to talk to a GDS

When you're building an OTA, you have three options:

1. NDC / Modern REST APIs

All three GDSs now have modern REST APIs built on the IATA NDC (New Distribution Capability) standard. These are developer-friendly, JSON-based, and relatively well-documented.

The catch: NDC offers a different content set than "traditional" GDS content. Not all airlines are fully on NDC. You'll often miss fares that only exist in the traditional inventory.

2. Web Services (SOAP/XML)

One generation behind NDC. Amadeus Web Services (AWE), Sabre Web Services — these are SOAP-based XML APIs. Ugly but battle-tested and complete. Most production OTAs still use these for core booking flows.

A typical Amadeus fare search response looks something like this:

<OTA_AirLowFareSearchRS>
  <PricedItineraries>
    <PricedItinerary SequenceNumber="1">
      <AirItinerary DirectionInd="OneWay">
        <OriginDestinationOptions>
          <OriginDestinationOption>
            <FlightSegment DepartureDateTime="2026-07-01T06:30:00"
                           ArrivalDateTime="2026-07-01T08:15:00"
                           FlightNumber="123">
              <!-- 400 more lines of XML -->

You learn to love it. Or you learn to cope with it. One of those.

3. Aggregators / Content APIs

Companies like Duffel, Kiwi, or Travelfusion sit between you and the GDS, offering clean REST APIs and handling the GDS complexity for you. You pay more per booking, but you ship faster.

This is actually the right choice for most startups. Don't build GDS integration yourself until you have real booking volume and a compelling reason to save on per-booking fees.

The booking flow, step by step

Here's what happens when a user books a flight through a well-built OTA:

1. Low-fare search (LFS) You send origin, destination, dates, passengers. The GDS returns up to 200+ priced itinerary options. This is the most compute-intensive step — a single search can generate hundreds of API calls behind the scenes.

2. Fare verification Before you show the price to the user, you re-verify it. Fares change in milliseconds. The price in the search result is often already stale by the time the user clicks it. Always re-price before checkout.

3. PNR creation When the user confirms, you create a Passenger Name Record (PNR) — the booking record in the GDS. This is a 6-character alphanumeric code (the "booking reference" your airline gives you).

4. Ticketing Creating a PNR doesn't issue a ticket. Ticketing is a separate step that converts the booking into an actual e-ticket (an IATA EMD or ET document). You have a ticketing time limit — usually 24-72 hours — before the PNR expires.

5. Mid-office After ticketing, the booking enters your mid-office: the backend systems that handle amendments, voids, refunds, commission calculations, supplier invoicing. This is where most OTAs have their biggest operational complexity.

The painful parts nobody tells you

Fare families and ancillaries: Modern airline fare structures are nightmarish. The same flight might have 6 fare classes with different bag allowances, change fees, seat selection policies. Mapping this cleanly in your UI is genuinely hard.

Multi-currency: Airlines price in their local currency. You display in user's currency. Exchange rates fluctuate. Your commission is in a third currency. The accounting across a single booking can involve 4-5 currency conversions.

Error handling: GDS error codes are not HTTP status codes. They're things like ER0078: SEGMENT SOLD OUT - REQUEST ALTERNATE and you need to handle hundreds of them gracefully in your UX.

PCI-DSS: You're touching payment card data in the context of a booking. This means scope assessments, tokenization, careful logging hygiene. Don't skip this.

What I'd tell my past self

When I first integrated Amadeus, I spent three weeks building infrastructure for edge cases that represented less than 0.1% of bookings. I should have shipped the happy path first and handled exceptions reactively as real users hit them.

The 80/20 principle is especially true in travel tech. Most bookings are simple round-trips or one-ways on major carriers with standard fares. Get that right first. The multi-city, mixed-carrier, complex-ancillary flows can come later.

Also: find a good sandbox testing environment early and invest in proper test data. Testing GDS integrations against production is how things get embarrassing.

This is a world I find genuinely fascinating — there's something satisfying about understanding the infrastructure that moves hundreds of millions of people a year. If you're building in this space and want to talk through architecture decisions, my contact form is right there.