Travelport API Integration: Practice Guide Based on Experience

AltexSoft has extensive hands-on experience working with global distribution systems (GDS) APIs. Earlier, we shared our key takeaways from integrating with Sabre and Amadeus. Now, let’s turn to the last in the Big Tree—Travelport—and explore the specific challenges and nuances you’re likely to encounter when working with this platform.

What is Travelport—key things to know

Travelport is a major GDS that connects travel resellers (mainly travel agencies) with suppliers (airlines, hotels, cars, rail, and ancillaries). It’s the smallest, by revenue and market share, of the top three GDSs.

The Travelport brand brings together three legacy GDSs—Galileo, Apollo, and Worldspan—which were acquired and merged into Travelport through a series of deals in the early 2000s. Headquartered in Slough, Berkshire, a town just outside London in the UK, Travelport operates in more than 180 countries worldwide.

Among Travelport’s clients are online travel agencies (OTAs), travel management companies (TMCs), air consolidators, other travel resellers, and corporations. They can search, compare, and book various inventory.

Flights. Travelport provides access to over 470 airlines, more than 360 branded fares, and ancillary services from around 150 carriers.

Hotels. Through its GDS, Travelport connects to over 300 global hotel brands and Booking.com, offering more than 3 million accommodation options worldwide. The platform also guarantees commissions and benefits from over 45,000 participating hotels.

Other travel content. Travelport distributes content from:

• 42 car rental brands, including Hertz prepaid rates;
• 35+ rail operators across Europe, Asia, and other regions; and
• packages from major cruise lines and tour operators.

In 2022, Travelport integrated with Trainline—Europe’s leading rail booking platform—enabling GDS clients to purchase and manage cross-border train travel across Europe. The company was also the first GDS to introduce the New Distribution Capability (NDC) channel. Currently, agencies can source deals from 26 NDC airlines.

The company’s core product is Travelport+, a modern multi-source retailing platform that aggregates and normalizes content from traditional GDS feeds (airlines, hotels, car rentals, rail, and other travel sources), as well as NDC connections and low-cost carriers (LCCs). Sellers can search, compare, and book travel from a single marketplace via cloud-based tools and the desktop application Smartpoint, which sits on top of the Travelport+ platform.

Another way to search for and book inventory is through API connections, which allow agencies to integrate travel content and services directly into their own applications. For those who are unfamiliar with how APIs work, we’ve created an explainer video.

Travelport APIs are bifurcated into two distinct but complementary families of services, each governed by different protocols and data models: the Universal API (XML APIs) and the API Suite (JSON APIs). AltexSoft has hands-on experience with the former, but we studied the documentation on both.

Before diving into the technical integration, a travel company must first navigate a fairly extensive business discovery and negotiation phase.

Business negotiations: how to become a Travelport-connected agent

The first step is contacting the sales department by filling out the online form. You need to provide your company’s basic business details (such as name, website, country, and contact information), as well as management and tech team contacts, and explain the intended use case—internet booking engine, online booking tool (OBT), mid/back office, mobile booking app, or something else—for accessing the APIs.

After submission, a Travelport representative usually contacts you to discuss your application and pricing. Central to commercial negotiations is an agency’s ability to handle financial settlements and risk management. Travelport generally works with agencies through two operational paths, depending on accreditation status.

Accredited ticketing agencies. To issue airline tickets directly, you must hold an IATA accreditation (globally) or an ARC accreditation (US). This identifies your agency within the airline settlement frameworks—Billing and Settlement Plan (BSP) or ARC.

Non-accredited agencies. Non-IATA/ARC agencies can operate under the umbrella of a host agency or an air consolidator, which will hold the ultimate ticketing authority and financial responsibility. The non-accredited agency must provide full details of its partner during onboarding.

Besides your or your host agency's accreditation, you must demonstrate that your business is a legally registered, professionally operated travel seller capable of meeting Travelport’s operational and commercial requirements. During the onboarding process, agencies are typically asked to provide:

• official incorporation documents and tax identification;
• a description of their business model (B2B, B2C, or Corporate/TMC), including expected booking volumes and look-to-book (l2b) ratios;
• bank references or guarantees may be requested, particularly for agencies in higher-risk and emerging markets.

After the sales department evaluates your info, they will send a commercial proposal. Pricing is tailored to your setup. Recurring annual API access fees ($5,000) include standard support and certification for the first product. Certification of any additional software solutions is subject to a separate one-time charge, and certain GDS services and products may incur additional monthly fees.

Once the contract is signed, you register for a developer account on the Travelport Developer Portal to start technical work.

In the sections below, we’ll outline the key characteristics of Travelport APIs and explain how to implement them in your solution.

Universal API: for enterprise-level booking tools and mid/back-office synchronization

The Universal API (formerly uAPI) is a mature set of SOAP/XML-based web services. It brings under one roof access to core GDS inventory—traditional (EDIFACT) air content, selected low-cost carriers, branded fares, ancillaries, hotels, car rental, and rail, providing a foundation for building full-service web, mobile, or desktop travel apps.

The Universal API is particularly suited for complex workflows, back-office and mid-office synchronization, and enterprise-level booking tools that rely on the full depth of traditional GDS business logic.

However, it has a significant limitation when it comes to modern air retailing. While the Universal API has been extended over time to surface NDC content and retrieve certain reservations created through other channels, it is not designed to support the end-to-end NDC workflow—from shopping and offer management to post-booking servicing. For native NDC use cases, Travelport offers its modern, REST-based API suite as the primary solution.

Universal API catalog

Universal API is structured as a single gateway that provides access to four primary services, along with two additional ones.

Air Service boasts robust flight functionality, including low-fare shopping, diverse fare choices, and seamless ticketing. It connects to 400+ airlines, and supports negotiated fares and ancillary merchandising.  

Hotel Service enables hotel search and reservation by aggregating property data from Travelport and third-party hubs (primarily Booking.com). It returns enriched content including room images, amenities, and granular rating data.  

Vehicle connects resellers to 42 major car rental brands across approximately 38,000 locations worldwide. Users can search available cars by pickup location, date, and time; get car details, images, reservation policies, and additional charges; and book,  modify, or cancel reservations.

Rail provides access to five global rail carriers, delivering real-time train schedules, pricing, and ticketing. It is particularly relevant in the European market, where rail content is integrated to enable multimodal itineraries alongside air travel.

Travelport’s rail implementation aligns with broader European Union policy direction, making high-speed rail options available as alternatives to short-haul flights and supporting more sustainable travel choices.  

Profile allows you to create, modify, and delete profiles for users at various levels, from individual travelers and traveler groups to agents, agencies, and agency groups. It supports complex data structures (hierarchies) to ensure that travel preferences, loyalty information, and payment details are correctly inherited or applied during the booking process.

Universal Records and Bookings is the master management tool that serves as a Super PNR, containing information about the entire passenger’s trip (for instance, flights, car rentals, and hotel bookings). It can include several Passenger Name Records (PNRs).

How to build integrations with Travelport Universal API

Once your contract is signed, you get a welcome letter with credentials:

• UserID,
• password, and
• branch code that is tied to your Pseudo City Code (PCC).

Let’s take a closer look at what a branch code is and how it differs from a PCC.

A PCC is a core identifier for your company or its individual offices in Travelport. It defines your location, access rights, which airlines you are authorized to sell, and which fares and ticketing rules apply to you.

For example, if your company has two offices—one in New York and one in London—Travelport will assign a separate PCC to each location and store it in its system along with the rest of your company’s profile and provisioning data.

A branch code is an operational code linked to the PCC. You must include the branch code in every SOAP API call, as it tells Travelport which branch context and provisioning settings should be applied to the request.

Because different departments within the same office—for instance, a website and a call center—may have different access rights, multiple branch codes can be associated with a single PCC.

All credentials together allow you to authenticate your SOAP XML requests and interact with Universal API's pre-production system.

Travelport’s pre-prod environment. This environment offers the same functionality as the production system, but the data it contains—such as prices and availability—may differ slightly. This data is refreshed regularly and represents a partial copy of live production data. However, response times in pre-production are typically slower. See the Universal API docs and pre-production pages to find the endpoint lists.

The purpose of this environment is to allow users to evaluate product functionality. It should not be used to assess system performance or data accuracy.

Travelport provides developers with a robust testing ecosystem, including comprehensive WSDL and Schema files, a dedicated Universal API SDK, and code samples in the Universal API GitHub. It contains nine repositories, including sample tutorials in Java, PHP,  C#, and other toolkits. Developers often find public GitHub tutorials even more helpful than the SDK.

Testing tip from AltexSoft QA team: use Smartpoint (Travelport agency self-service booking tool) to manually verify PNRs and all the responses. Smartpoint lets you see how bookings should look for a user, making it much easier to spot and diagnose mismatches or errors in your API integration. 

Free trial. You can start with a 30-day trial to evaluate the API's capabilities before signing the contract. You’ll interact with Universal API's pre-production system via the sandbox. In this case, testing is limited to Air and Hotel services.

During the free trial, Travelport provides regional email addresses you can use for questions about account setup, access, and basic guidance.

Understanding booking flow

In the travel industry, the booking workflow—whether you’re reserving a hotel, a car, or a flight—follows three core steps: shop, price, and book. 

For example, the core flight booking workflow in Universal API looks like this:

• Air Shop: search for flight options by lowest fare (LowFareSearchReq) or availability (AirAvailability).
• Air Price: request updated price for the selected flights and additional information about rules, flight details, and seating.
• Air Book: book the flights when you are satisfied with the times, price, and rules.

Next possible steps include ticketing, cancellation, changes, or retrieving existing data from the system.

Each step may require a few requests or API calls. For instance, the Air Price step contains five calls: Air Price, Air Fare Rules, Flight Details, Flight Information, and Seat Map. Naturally, the air booking flow is the most elaborate; the flows for hotel and car rental are more straightforward.

Travelport simplifies the integration by executing low-level requests under the hood. “For instance, ‘create reservation' request automatically includes adding TST (Transitional Stored Ticket, a pricing record that holds all fare and tax information required for ticketing) and opening/closing a transaction. It’s simplified compared to Amadeus, for example,” says Andrey Dudnik, software engineer at AltexSoft, who dealt with Amadeus APIs while building a flight aggregator for OTA. 

“Travelport’s models—the structure for request and response—are logical, clear and consistent; particular fields placed where you expect them to appear, which is not always the case with some other GDSs”, comments Serhii Shkodenko, software engineer at AltexSoft, who worked on the same project.

Universal API uses a single endpoint for multiple services, so the specific action—air search, pricing, booking, ancillaries—must be defined inside the request body. In addition, each request must explicitly indicate the target GDS (Apollo, Galileo, or Worldspan) and include parameters tied to your office or Point of Sale (POS). “Depending on the POS, you might have different access rights, custom rules, or settings that are managed directly—either through your account or with an account manager. That’s pretty much standard practice across all GDS platforms,” adds Andrey.

To better understand and test how flight bookings, hotel bookings, and other workflows operate, developers can use official prototypes (demo apps).

How to move an app to production

Before going live, your app must be certified by Travelport. It requires at least 15 business days' notice before you intend to move to production.

To get certified, developers must capture detailed logs of the SOAP requests and responses, ensuring every transaction is correctly signed with the unique Target Branch and credentials. These logs must show that your app handles complex scenarios without errors.

“You have to run through the entire flow for several specific business cases”,  says Andrey Dudnik. “For instance, a standard scenario might be issuing tickets for a transatlantic round trip for one adult, one child, and an infant. This single business case covers everything—from the initial search and pricing to creating the PNR and actually issuing the tickets. You’ll typically need to complete about three or four of these scenarios, such as a multi-destination trip, adding paid baggage, or upgrading a fare. It’s nothing complicated”.

After you submit the logs, the Travelport API team will evaluate them and then set up a move-to-production call to discuss their review and any tweaks needed for peak performance. As soon as you’re certified, you’ll get a welcome letter with live credentials. 

Travelport+ API Suite (JSON API): for mobile-first applications and NDC booking

The Travelport+ JSON APIs are built on a microservices-based architecture, making them more granular and better optimized for speed and flexibility than legacy interfaces. You can integrate only the specific APIs you need.

Technically, Universal API also allows you to connect to just a single service. The difference is that all services still run within the same monolithic SOAP framework, so even a limited integration inherits the overall architecture's complexity. In contrast, the API Suite isolates services into lightweight, independent endpoints that are easier to build, scale, and maintain.

These APIs utilize the REST-based architecture and JSON payloads, which significantly reduce overhead compared to SOAP/XML integrations. JSON API Suite is preferable for high-performance, mobile-first applications.

The suite is organized around the Open Data Model (ODM), which standardizes attributes across different content sources, ensuring that a search response for a traditional legacy carrier appears structurally similar to an NDC offer or an LCC response. It explicitly supports NDC content.

While the newer interfaces are easier to work with, the legacy SOAP services still carry the heavy lifting for more complex or niche features that haven't been migrated over yet. “Typically, whether you're dealing with Amadeus, Travelport, or Sabre, their modern JSON APIs don’t quite cover the full range of functionality that the 'old-school' SOAP APIs do,” says Andrey Dudnik.

Travelport+ API Suite catalog

As of now, there are over 30 distinct REST endpoints in the Travelport JSON Suite, with the number expected to grow as Travelport continues migrating legacy functionality into the Travelport+ ecosystem.

JSON Air APIs aggregate content from GDS, NDC, and LCCs into a unified response, with logic primarily designed to support NDC bookings. For NDC content, ticketing and servicing are directly handled by the NDC carriers, while Travelport manages these processes for GDS content. As a result, the JSON APIs use different procedures to handle cancellations, voids, exchanges, and other post-booking actions for GDS and NDC bookings.

JSON Hotel APIs support the complete booking flow (modular APIs for search, rules, and booking) across over 150,000 properties, including traditional GDS inventory and content from aggregators like Booking.com. The SearchComplete API combines in one request what used to require at least three separate hotel API calls in the previous version (search, availability, and property details).

JSON Pay APIs provide a stable model for integrating payment features into custom booking engines. In particular, they allow online travel agencies to request credit card authorizations, card and address validations, and reversals against a specific vendor. In addition to global cards, airline-industry-specific payment methods–IATA EasyPay and UATP–are supported.

How to build integrations with Travelport JSON API

While the process is largely the same as with the Universal API, there is one key difference: the free-trial conditions are not explicitly outlined, though you can request them.

The credentials required for JSON APIs vary from those used in the Universal API and will include:

• username,
• password,
• client ID,
• client secret, and
• Travelport Access Group.

The client ID and client secret are essential for OAuth 2.0 authentication. Travelport Access Group—a configuration profile that controls what content, data, and system capabilities your application is permitted to access—is tied to PCC, just as the branch code in the Universal API.

To turn on NDC content, you may need to register PCC directly with the airline. This requirement is carrier-specific: some airlines mandate PCC registration as part of NDC activation, while others enable NDC access without additional airline-side registration.

Travelport’s Developer Portal provides comprehensive documentation for the API Suite, detailing the RESTful endpoints for Air, Hotel, and Pay services. Download the official JSON API Postman Collection to visualize how headers and body elements are constructed, from the DevKit to test endpoints immediately without writing code.

Unlike the legacy SOAP services, the JSON API Suite is built on OpenAPI (Swagger) specifications, allowing you to generate client libraries automatically in almost any modern programming language.

Note that NDC content is carrier-dependent: airlines differ in what they expose through NDC, including ancillaries and servicing features. Developers should test integrations thoroughly for each carrier they intend to support and consult Travelport’s Knowledge Base for per-carrier NDC capability details.

Understanding the booking flow

The JSON Air API Suite and JSON Hotel API Suite use different booking logic. While for booking a hotel you need to move through a sequence of calls (Search → Availability → Create Reservation, just like in Universal API), Air API uses another pattern, designed for a complex NDC workflow: a stateful workbench session.

Think of a workbench as a workspace or data container: once created, it stores all relevant data across multiple API calls. Information is added step-by-step before finalization. Once a reservation is made, any updates or changes—including ticketing—are processed within the workbench. This approach ensures that all parts of an itinerary are stored together with consistent context.

The workbench is especially useful for managing multiple travelers' reservations, adding ancillary services (such as seats, baggage, meals, etc.), and repricing when changes occur.

That’s how the JSON API air booking workflow looks:

• Search for flights: Query the available flights by providing search parameters like departure and arrival locations, dates, and traveler preferences to receive a list of possible flight options.
• Price: For certain low-cost and NDC carriers, pricing must be retrieved in a separate call to get accurate and up-to-date information for the selected flights.
• Create a workbench session: Start a new workbench, which holds all subsequent actions for a specific booking.
• Add offer: Add the selected flight offer from a search response into the workbench.
• Add traveler details: Populate traveler information into the workbench.
• Commit workbench: Submit the accumulated data to create a booking (reservation).
• Ticketing: In a separate or post-commit workbench session, provide payment details and commit them to issue tickets.
• Instant Pay (NDC only): Some carriers allow combining booking and ticketing in the same session.

Optional elements such as seats, ancillaries, remarks, or custom rules can be added either before or after the booking commit.

How to move an app to production

This process is also similar to what is needed for Universal API. Travelport provides the list of test scenarios, including a round-trip itinerary with a connecting flight, covering different passenger types (adult, child, and infant), as well as other business cases for air and hotels. For NDC carriers, there may be additional certification steps, such as validating order modification flows.

Developers must submit logs of the corresponding requests and responses, undergo a review from the Travelport support team, and address any identified issues. Once approved, the application can move to production.  

Where to get help

For customers operating under commercial agreements, technical support is governed by contractual terms. They define response times, escalation paths, and the scope of available technical assistance.

In practice, the service depth may depend on the customer tier.  Larger or strategically important partners typically receive faster assistance and more structured support processes, including agreed communication workflows and escalation mechanisms.

The central support hub is MyTravelport customer portal, where developers can submit support tickets, track case status, and access knowledge base articles. Besides, the GDS can assign a dedicated account manager.

“Since our client is one of the largest travel agencies in the Middle East, during the development stage we were assigned a manager,” says Serhii Shkodenko. “We contacted this person by email and usually received a response within a day, sometimes even before anyone read our ticket on MyTravelport. However, after going live, this changed: there is now no dedicated manager, and we sometimes have to wait weeks for a response from the support team.”

Of course, there are situations where waiting simply isn’t an option. In case of critical API issues, you can call Global Service Operations (GSO) desk, which works 24/7 in all regions.

In addition to official support channels, developers discuss Travelport APIs on Stack Overflow under the “ travelport-api” tag. There have been dozens of Travelport-specific programming questions over the last few years, but the volume is much lower than in larger API ecosystems like Sabre or Amadeus.