GDS Integration Explained: Amadeus, Sabre and Travelport
By Travel White Label · Published 11 November 2026 · Updated 11 November 2026
GDS integration means connecting your booking platform to a global distribution system (Amadeus, Sabre or Travelport) through its APIs, using your agency's own office identity and credentials, so your website can search fares, create bookings, issue tickets and handle changes without anyone retyping data into a terminal. It is not a plug-in you switch on. It rests on five things: a commercial agreement with the GDS, an office ID or pseudo city code (PCC), API credentials, ticketing authority, and software that handles the whole booking lifecycle. Our GDS integration and travel API integration page sets out how we scope these connections.
This guide is for online travel agencies (OTAs) weighing up a direct GDS connection: how each piece works, what changed at Amadeus in 2026, how Sabre and Travelport issue credentials, what happens to a booking after it is made, and who pays whom. If you are still choosing between flight and hotel content sources, start with our pillar guide to GDS vs hotel bedbanks. The segment example below is an illustration, not client data.
In this guide
The five building blocks of a GDS connection
Amadeus, Sabre and Travelport: how each connection works in 2026
The PNR lifecycle your integration has to handle
Ticketing: IATA and BSP, or a consolidator
The commercial side: segment fees, incentives and your contract
Own GDS credentials vs our suppliers: which route fits you
GDS integration checklist, key takeaways and FAQs
The five building blocks of a GDS connection
"We want Sabre on our website" really means five separate things, each with a different owner. A gap in any one stops a live booking.
The commercial agreement. A contract between your agency and the GDS provider covering which products you can use, in which markets, and on what terms. Sabre's New to Sabre checklist says that to use a Sabre API in production you "will first need to agree to our commercial terms and conditions", and that your account manager is the first point of contact.
The office identity. Every GDS models your agency as a virtual office. Sabre calls it a pseudo city code (PCC) and describes it as "an alphanumeric identifier that defines your Sabre workspace", where you "place reservations and manage your daily operations". Amadeus uses an office ID; Travelport also uses PCCs. Content, ticketing set-up and much of your configuration hang off this identity.
API credentials. The usernames, passwords and client keys your platform uses to sign in on your office's behalf, separate from staff terminal logins.
Ticketing authority. The right to issue airline tickets, which comes from IATA accreditation, a consolidator or an agreement with an airline. The GDS supplies the tools to issue a ticket; it does not give you the authority to do so.
The booking software. The platform that turns API calls into a customer journey: search, re-pricing, passenger forms, payment, confirmations and an admin view. This is the part a white label provider supplies.
Our integrations page puts the key questions plainly: a scope review "should establish which sources you intend to use, which markets you sell in, and who holds the commercial agreement and ticketing authority".
Amadeus, Sabre and Travelport: how each connection works in 2026
All three follow the same pattern: a sales conversation, a contract, provisioning of an office and credentials, non-live testing, then production access. The details differ, and Amadeus changed significantly this year.
Amadeus: Enterprise access only since July 2026
Amadeus's Self-Service tier, where anyone could get test keys in minutes, has gone. In February 2026 PhocusWire reported that Amadeus would pause new registrations and decommission the Self-Service portal on 17 July 2026, with API keys disabled from that date. An Amadeus spokesperson said only the self-service section was closing and that "the Enterprise portal and Enterprise APIs remain fully available". The Amadeus developer guides repository on GitHub is now archived and opens with the notice that the Self-Service offer "has been deprecated".
A new Amadeus connection now starts with a commercial conversation about Enterprise access, tied to your office ID; Self-Service tutorials no longer describe a route you can take. Our Amadeus API integration guide covers the Amadeus steps and trade-offs in more depth.
Sabre: PCC, EPR and two API styles
According to Sabre's New to Sabre checklist:
When your account is created you receive an SC code linked to your contract and a PCC.
With your account manager you place an API order, choosing options such as the number of API sessions you can use at a time.
The order is linked to a robotic Employee Profile Record (EPR), the system user your software signs in as, and you receive a temporary password to replace with a permanent one.
Sabre's authentication guide then describes two styles. REST APIs are sessionless: the platform requests an OAuth token using the EPR, PCC, password and a client ID and secret. SOAP APIs use sessions, with a 15-minute inactivity timeout and a limit of 50 sessions per customer, so the platform needs a session manager.
Sabre also separates a certification ("CERT") environment from production. Its environments guide says you can send and cancel test passenger name records in CERT, and warns that any test bookings made in production must be cancelled, or "you and possibly your customers will be billed by suppliers or other vendors for all associated fees". So agree, before go-live, who may make test bookings on the live system.
Travelport, including Galileo
Travelport's help pages note that "Travelport+ is the new name, and reference, to Galileo (1G)". Travelport has two interface families: the older Universal API, also called the SOAP XML API, and the newer TripServices JSON APIs, which use OAuth 2.0.
Travelport's authentication guide explains that it assigns each organisation usernames and access groups based on its points of sale. An access group "contains information about an organization, including PCC, location, currency, NDC and GDS carrier information", and it decides which content your application can see. Production and pre-production credentials are issued at provisioning and managed through MyTravelport.
The same GDS can show different content depending on how your office or access group is set up. If a carrier you need is missing, the fix is often in provisioning rather than code.
Behind the APIs: EDIFACT, NDC and JSON
Three layers of technology sit behind any of these connections:
EDIFACT. The long-established messaging standard behind much of the airline and reservation world. IATA's developer portal lists EDIFACT implementation guides for passenger reservations and for airport services such as check-in, baggage and ticketing.
NDC. IATA describes NDC as "a new, XML-based data transmission standard" based on offers and orders, open to "any third party, intermediary, IT provider or non-IATA member" (IATA NDC). The airline returns a priced offer, often bundled with bags or seats, that expires after a set time; booking it creates an order.
The GDS's own API. Your platform rarely speaks EDIFACT or raw NDC. It calls the GDS's SOAP or REST/JSON web services and the GDS translates, which is how one connection can return both kinds of content.
This matters after the sale. As our integrations page puts it, "GDS and NDC connections may expose those steps differently": for NDC content, confirm "offer expiry, order creation and supported changes or cancellations with the relevant provider". Before you sign, ask each GDS which of your key airlines come through NDC and which servicing actions work through the API for each.
The PNR lifecycle your integration has to handle
A passenger name record (PNR) is the booking file inside the GDS. Travelport's Universal API documentation describes it simply: a PNR "is created by a provider when a travel segment (air, vehicle, or hotel) is booked and saved", and one PNR can hold several segments (content providers and suppliers). What matters for a website is everything that happens around that record.
Shop. The platform searches and receives priced options, often partly cached.
Validate the price. Before payment it re-prices the exact itinerary. Our integrations page says an integration "should distinguish a price that has been displayed from a price that has been validated for booking".
Create the booking. Segments, passenger names, contact details and a ticketing arrangement are added and the record is saved.
Ticketing time limit. Airlines usually set a deadline for issuing the ticket. Miss it and the seats can be cancelled.
Take payment. Through your payment gateway, before or at the moment of ticketing.
Issue the ticket. By whoever holds ticketing authority for that booking (see the next section).
Watch for changes. Airline schedule changes arrive after the sale; someone must pick them up and tell the customer.
Service. Voids, exchanges, refunds and cancellations, each under the fare rules and any time limits that apply.
Reconcile. Match each booking, ticket and payment.
The failure that costs the most
The expensive error is an uncertain booking: the request times out and nobody knows whether the PNR was created. Retrying blindly can create a duplicate; giving up can leave a live booking unpaid. Our integrations page notes that error handling, timeouts and duplicate requests matter because "staff need to know whether a booking failed, succeeded or needs investigation before they attempt it again". Ask any provider to show you, in a demo, what happens in that situation.
Ticketing: IATA and BSP, or a consolidator
Turning a booking into a ticket needs authority from the airline, usually obtained one of two ways.
Your own IATA accreditation
IATA's travel agent accreditation gives a unique agency code, membership of the Billing and Settlement Plan (BSP) and a single sales agency agreement covering many airlines. IATA offers several options, including GoLite, described as a simplified route with "no minimum financial guarantee required to issue air tickets", and GoStandard, which gives access to all IATA standard payment solutions. Tickets are then issued in your name and settled through BSP.
Ticketing through a consolidator
Many OTAs book in their own PCC but have tickets issued by a consolidator that holds the authority, sets deadlines, payment terms and fees, and handles some after-sales work. It is a common way to start, but your customer's ticket is then only as fast as your consolidator's process.
Where ATOL comes in
Ticketing and licensing are separate questions. The CAA's guidance on airline ticket agents sets narrow conditions for ATOL-exempt flight-only sales, including issuing a confirmed ticket immediately on payment. If you sell flights with hotels, the government's package travel guidance for businesses also applies. A GDS integration never gives you an ATOL. TravelWhiteLabel does not hold an ATOL either; our suppliers are ATOL and ABTA protected, and you can check any licence on the CAA's ATOL holder search. This is general guidance, not legal advice.
The commercial side: segment fees, incentives and your contract
The UK Competition and Markets Authority set out how GDS money flows in its final report on Sabre and Farelogix (April 2020), which blocked that merger.
Traditional model. The CMA describes a model where "the airline pays the GDS a fee for each travel segment", and the GDS in turn pays the agency that made the booking an "incentive fee". The GDS keeps the difference.
Other models. In a wholesale model the airline pays the agent and the agent pays the GDS a technology fee; in airline "private channels", agents "receive lower or no incentive payments from the GDS".
The CMA notes that "a return ticket booked through a GDS will incur a fee charged to the airline for both the outward and return segments".
What that means for your contract
Count segments, not bookings. As an illustration, a non-stop London to New York return is two segments; the same trip with one connection each way is four. Any incentive or fee in your contract that is set per segment scales with that count.
Read the volume terms. Ask whether terms depend on booking volumes and what happens if you fall short or leave early.
Ask about API charges. Ask each GDS what, if anything, you pay for API access, test environments and support.
All of this sits in your contract with the GDS, not with us. Charges from your own GDS or payment gateway are not included in our fees.
Own GDS credentials vs our suppliers: which route fits you
There are two ways to get GDS flight content onto a TravelWhiteLabel site.
Route 1: connect your own GDS credentials
Suits: OTAs that already hold an Amadeus, Sabre, Travelport or Galileo agreement, negotiated fares or their own ticketing arrangement.
What you do: confirm with your GDS that API access is enabled for your office, share connection details with us through a secure channel (never send passwords or private keys by email or web form), and test before go-live. Our integrations page says the supplier "must confirm the permitted products, markets and use of its inventory".
Cost: your GDS charges and incentives follow your own contract, separately from our plans.
Trade-off: more control, your own fares and your own relationship with the GDS, but more contracts, more provisioning and more responsibility for ticketing and servicing.
Route 2: use our suppliers
Suits: OTAs launching flights for the first time or testing a new market.
Cost: no extra cost for using our suppliers.
Protection: our suppliers are ATOL and ABTA protected.
Trade-off: you sell the content and fares those suppliers offer. Ask us in the demo which airlines and routes are strongest for your market and how ticketing and changes work.
How long a GDS integration takes
No honest provider gives a fixed period before scoping. Our integrations page lists what drives the schedule: "commercial approval, documentation quality, sandbox access, certification and your team's acceptance testing". Standard white-label configurations on supported integrations can be ready in as little as 3 working days, but new supplier API integrations may take longer. A new GDS contract is often the slowest part, and its pace is set by the GDS.
What TravelWhiteLabel costs
Setup fee: none.
Growth, £179 a month: B2C booking portal, admin dashboard, flight and hotel search engines.
Scale, £599 a month: adds the B2B portal, markup automation, package builder and multi-currency support.
Elite, £999 a month: adds custom API integrations, workflow automation and a dedicated account manager.
API access, £999 a month: API access to all our products, for example to connect a partner site or app to your platform. It is separate from any GDS contract.
Free beta site: billing starts only at go-live. Pay 12 months upfront and get 2 months free.
See all plans and pricing.
GDS integration checklist
Work through this before your first live ticket:
List the airlines, routes and markets you need, and the share of NDC versus classic content for each.
Confirm your commercial agreement covers API access for your office, in writing.
Confirm your test environment and who may make test bookings in production.
Decide who issues tickets: your IATA accreditation, a consolidator or an airline agreement.
Agree how ticketing time limits are tracked so no booking lapses unticketed.
Test the full lifecycle: search, re-price, book, pay, ticket, void, exchange, refund and cancel.
Test the awkward cases: price change at re-pricing, sold-out fare, failed payment and a timed-out booking request.
Read your GDS contract's segment, incentive and volume terms.
Check your ATOL position for each flight product you sell.
Confirm your payment gateway and PCI DSS responsibilities (see the PCI Security Standards Council's FAQ on outsourced payment processing).
Key takeaways
GDS integration needs five things: a GDS contract, an office ID or PCC, API credentials, ticketing authority and booking software. A white label platform supplies only the last one.
Amadeus closed its Self-Service APIs on 17 July 2026; new direct connections go through Amadeus Enterprise.
Sabre provisions a PCC and a robotic EPR, with sessionless REST and session-based SOAP APIs; Travelport (Travelport+ is the new name for Galileo) uses access groups linked to your PCC.
NDC offers expire and become orders, so servicing can differ from classic GDS bookings; check each key airline.
The integration must handle the whole PNR lifecycle, including ticketing time limits, schedule changes and uncertain booking status.
GDS fees and incentives follow your own contract and are not included in our fees; our suppliers cost nothing extra and are ATOL and ABTA protected.
FAQs
What is GDS integration?
Connecting your booking website to Amadeus, Sabre or Travelport through their APIs, using your agency's office ID or PCC and credentials, so customers can search, book and get tickets online.
Do I need my own GDS contract to sell flights online?
No. You can use our suppliers at no extra cost, and they are ATOL and ABTA protected. A contract of your own makes sense if you already have negotiated fares, ticketing authority or a GDS relationship you want to keep.
Can I still get a free Amadeus API key?
Not through Self-Service, which Amadeus decommissioned on 17 July 2026. Direct access is now through Amadeus Enterprise, after a commercial conversation with Amadeus.
Do I need IATA accreditation for GDS integration?
Not for the connection itself, but someone must hold ticketing authority. That can be your own IATA accreditation, which gives access to BSP, or a consolidator that issues tickets for bookings made in your office.
Which GDS integrations does TravelWhiteLabel support?
Amadeus, Sabre, Travelport and Galileo for flights, alongside hotel suppliers TBO, Stuba, Ratehawk, HotelBeds and DOTW. Availability depends on your agreement with each supplier, so tell us what you hold and we will confirm what can be connected before any project starts.
See GDS integration working on your own site
Book a live demo and see search, booking and ticketing with your own Amadeus, Sabre or Travelport credentials, or with our suppliers at no extra cost. There is no setup fee, you start on a free beta site, and billing starts only at go-live. Book a live demo, compare plans and pricing, or call our East Ham, London E6 team on 020 3432 6375 (Mon-Fri 9:00-18:00) or email [email protected].