How to Integrate the Travelport API into a Travel Portal

This is the third guide in a set. I've already covered integrating the Amadeus API into a B2B travel portal and integrating the Sabre API. The core idea is the same on every GDS: a search result is a snapshot, the price must be confirmed before you take money, and booking and ticketing are separate steps. What changes is how you get access, how you authenticate, and how the booking itself is assembled. On Travelport, that last part is the most different.

If you're still choosing a GDS, read Sabre vs Amadeus vs Travelport first. This post assumes Travelport is the right fit for your markets or your agency already has a Travelport contract, and now someone has to build it.

First, untangle the names

Travelport's history is a series of mergers, and the names in its documentation reflect that:

• Galileo (host code 1G), Apollo (1V) and Worldspan (1P) are the GDS host systems Travelport runs. Most customers get their content from Galileo.
• Travelport+ is the current name for the Galileo-based platform. When a sales conversation says "Travelport+", it means 1G.
• Universal API (often "uAPI", also called the SOAP XML API) is the older, broad web-service interface covering air, hotel, car and rail.
• JSON APIs (the Flights, Stays and Pay APIs, presented on the developer portal as TripServices) are the newer REST interface. Versions before 11 were deprecated at the end of 2022, so v11 is the baseline.

The host code matters in practice: your PCC belongs to one host, and you'll see values like 79JP_1G where the PCC and host are sent together.

Universal API or JSON APIs?

For a new air-focused portal, my default is the JSON APIs. They're REST with JSON, use standard OAuth tokens, are where Travelport's NDC content is delivered, and are far pleasanter to work with from .NET or Node than a large SOAP schema.

The Universal API is still supported and still runs a lot of live portals. Travelport even put its uAPI schema-retirement process on hold in January 2025, so existing integrations aren't being forced to upgrade. Choose it when you're extending a portal that already speaks uAPI, or when a workflow you need isn't covered by the JSON APIs for your content. Don't guess on this: list the exact operations you need (search, price, book, ticket, cancel, exchange, refund, seats, ancillaries) and confirm with Travelport which interface supports each for your PCC.

Access: trial credentials, provisioning and the access group

Like Sabre, Travelport has no sign-up-and-go production tier. Access comes in stages:

• Trial credentials from a sign-up form on the developer portal. Good for learning the request shapes.
• Pre-production and production credentials, issued at provisioning once there's a commercial agreement. That agreement normally sits with a travel agency or partner, not with the developer building the portal. You'll get a username, password, client ID and client secret, plus a welcome letter with your access group.

The access group is the piece developers don't expect. It holds your organisation's Travelport configuration: the PCC, location, currency, which GDS and NDC carriers you can sell, and printer links. Each API user has at least one, and it travels with your requests so responses match your point of sale. A B2B portal working across markets may have several, so treat it as per-tenant configuration, never a constant.

Authentication: one 24-hour token, cached

The JSON APIs use OAuth 2.0 with the password grant. You post your credentials to the token endpoint and get back a bearer token valid for 24 hours:

// C#: get a Travelport token (pre-production host shown)
var form = new FormUrlEncodedContent(new Dictionary<string, string>
{
    ["grant_type"]    = "password",
    ["username"]      = cfg.Username,
    ["password"]      = cfg.Password,
    ["client_id"]     = cfg.ClientId,
    ["client_secret"] = cfg.ClientSecret,
});
var res = await http.PostAsync("https://auth.pp.travelport.net/oauth/token", form);
// cache access_token until shortly before expires_in (86,400 seconds)

// Every Flights API call then carries:
// Authorization: Bearer {token}
// XAUTH_TRAVELPORT_ACCESSGROUP: {access group from your welcome letter}
//   (or, in v11, TVP-PCC-CORE: {PCC}_{host}, e.g. 79JP_1G)
// Accept-Version / Content-Version: 11  (where the operation requires them)

Travelport is explicit that you should cache the token and not request a new one per call. Keep one per set of credentials, store it with its expiry, and refresh it a little before the 24 hours are up. Production lives on auth.travelport.net and api.travelport.net; pre-production adds .pp. Make the hosts and credentials configuration per environment and per tenant.

The core flow: search, price, workbench, ticket

On the v11 Flights API the shape is:

1. Search (catalog/search/catalogproductofferings). Results come back as catalog product offerings: each combines flights with a fare brand and its price and terms. There are also next-leg and flight-specific searches for building journeys leg by leg, and an Air Availability call that returns seats without prices.
2. Price (price/offers/buildfromcatalogproductofferings). Travelport describes this as optional for most carriers and required for some NDC and low-cost carriers. My advice: price the selected offer every time before you take money. It's the step that tells you the fare you're about to charge is still the fare.
3. Book in a workbench. A booking isn't one call. You create a reservation workbench, add the offer, add at least one traveller, then commit. The commit returns the record locator and creates a held booking: confirmed by the airline, not yet ticketed.
4. Ticket in a second workbench. Open a workbench on the existing booking, add a form of payment, add the payment, and commit. That's when tickets are issued and money actually moves.

There's also Unified Checkout (book/reservation/reservations/build), which adds the offer and travellers and commits in a single request without an explicit workbench. It's simpler for straightforward bookings; the step-by-step workbench gives you more control when you need to add extras or handle errors between steps.

The timers that will bite you

The workbench model comes with clocks, and your UX has to respect them:

• Search results stay in cache for 12 minutes for GDS content and 34 minutes for NDC content. Pricing and booking by reference only work inside that window. A customer who leaves a tab open and comes back 20 minutes later needs a fresh search, not an error.
• A workbench is valid for 30 minutes. If it isn't committed in time, it expires and its contents are discarded. Don't open the workbench when the customer lands on the checkout page; open it when you have everything you need to commit.
• Held bookings have a ticketing deadline set by the airline. Miss it and the booking is cancelled. Track it on every booking and alert a human before it passes.

Reference payloads, full payloads and NDC

Travelport requests come in two styles. A reference payload points at identifiers from an earlier response ("price this offer from that search"). A full payload sends the complete itinerary without referring back, which lets you book something that didn't come from a Travelport search. GDS content supports both. NDC content, in most cases, only supports reference payloads.

That has a design consequence: your offer model has to keep Travelport's identifiers from search all the way to booking, and it needs a content-source field so the booking code knows whether a full payload is even an option. NDC also needs its own provisioning and airline registration, its identifiers include the carrier code, and for NDC the form of payment is normally added at ticketing. Build the offer model for both content types from the start; retrofitting NDC into a GDS-only model touches search, booking, servicing and the admin panel.

PCCs and access groups in a B2B portal

A consumer site might run on one access group. A B2B portal rarely does: different markets, currencies or contracted fares often mean different PCCs. The rule is the same one I give for Sabre: resolve the access group (or PCC) per request from your own tenant and routing rules, and store it on every booking. When finance asks why two agents saw different prices for the same flight, that field answers the question.

The rest of the B2B layer doesn't change with the GDS: server-side markup that turns net fares into sell fares, agent wallets as an immutable ledger, roles per agency, and rate limits per tenant. The Amadeus B2B guide covers those in detail, and all of it applies here.

Keep Travelport behind an adapter

Travelport's responses are deep and full of its own concepts: catalog offerings, product brands, workbenches, receipts. None of that should leak into your business code. Define your own types (an offer, a price breakdown, a booking result, a ticketing result) and write a Travelport adapter that translates both ways. The adapter also owns the workbench lifecycle, so the rest of your system just calls "book this offer for these travellers" and gets a result or a typed error.

The payoff is the same as with any supplier: you can test the booking flow without calling Travelport, upgrade API versions in one place, and add Sabre, Amadeus or a direct airline feed as another adapter rather than a rewrite. I've written up that design in how to integrate multiple GDS providers into one booking engine.

Pitfalls I'd flag before you start

• Start provisioning on day one. Trial credentials are for learning. Real pre-production access depends on the commercial agreement, and that takes time.
• Cache the token. One per credential set, refreshed before 24 hours. Never one per request.
• Treat the access group as data. Resolve it per tenant or route, and record it on every booking.
• Design around the timers. 12 or 34 minutes for search results, 30 for a workbench. Re-search gracefully instead of failing.
• Always price before you charge, even where Travelport says it's optional.
• Separate booking from ticketing. Track the ticketing deadline and alert a human before it passes.
• Carry identifiers end to end and mark each offer as GDS or NDC.
• Log every request and response. With credentials masked, and searchable by record locator. Support will need it daily.

Travelport's workbench model feels unusual for the first week, then it starts to make sense: it's an explicit transaction around a booking, with a clear commit point. Get access, tokens and the money flow right first, respect the timers, keep Travelport behind your own interface, and it becomes a solid source of content for a portal you can grow.

Travelport API FAQs

// WRITTEN BY

Sunny Badgujar

Full-stack developer · .NET, React, SQL Server & Shopify · Jaipur, India

I build and run a live travel reservation platform connected to four GDS / supplier integrations, and I've built admin platforms for enterprise teams. I write about the problems I actually solve for clients.

About me LinkedIn Book a free 30-min call