Travelport API Integration: A Decision Guide for Travel Companies

Connecting to a GDS is rarely held up by the code alone. Projects usually slow down because of what surrounds it: the commercial agreement, ticketing authority, the choice of API, and a certification review that many teams forget to put in the plan.

This guide is for travel agency owners, product managers and technical leads who are deciding whether and how to integrate Travelport. It covers the decisions to make before anyone writes a line of code.

Is Travelport the right GDS for you?

Travelport is one of the three major global distribution systems, alongside Amadeus and Sabre. It gives travel sellers one connection to air, hotel, car and other travel content. If the term is new to you, start with our guide to what a GDS is.

Before you commit, ask three practical questions:

• Does it cover your routes? Take your 20 busiest routes and compare the airlines and fares you would actually get. Global airline counts tell you very little about your market.
• What will it cost per booking? Look beyond the access fee and compare incentives, segment commitments and any penalties for low volume.
• What do you already use? If your team works in another GDS every day, moving has training and process costs. Adding Travelport as a second source may make more sense than replacing what you have.

What you need before you start

Sort these out early. They affect your timeline more than the development work does.

A way to issue tickets

To ticket in your own name, you generally need IATA accreditation (ARC in the United States) and the settlement arrangement that goes with it. If you do not have this yet, a host agency or consolidator can issue tickets on your behalf, though your margin and control will depend on that agreement.

A commercial agreement

API access comes through a contract with Travelport. Expect to share company documents, your business model, and your expected booking and search volumes. Be realistic about those numbers, because they shape the deal you are offered.

On cost, reports an annual access fee of about US$5,000, with extra charges possible for further certifications and some services. Use this for early budgeting only, and get your own written quote.

A clear scope for version one

Write down what you will launch with: one-way and return flights only, or multi-city too? Hotels at launch or later? Who handles changes and refunds? A short, firm list makes both API selection and certification much easier.

SOAP or JSON: choosing your API

Travelport offers two API families. Its documentation calls them SOAP XML API Services (formerly uAPI, or Universal API) and RESTful JSON APIs.

Do not decide on the format alone. Make a list of every function your scope needs, then confirm in Travelport's current documentation which API supports each one. Some older functions may not have moved to JSON yet, and that single gap can decide your choice.

A company can also use both, but that means maintaining two integrations. Keep it simple unless you have a clear reason.

The integration roadmap

1. Get access and understand your credentials

After signing, you get test access and credentials. Find out early how your Pseudo City Code (PCC) is set up, because it controls things like your location, permissions, airline access and ticketing rules. Many confusing test results come down to PCC configuration, not code.

2. Build a thin version of the booking flow

Start with one complete journey: search, confirm the price, create the booking, issue the ticket, then cancel it. Add extras only after that path works from start to finish. A polished search screen means little if your team has not proven it can ticket.

3. Design for the unhappy paths

Travel bookings fail in ways that ordinary e-commerce rarely does. Plan for these from the start:

• The fare changes between search and booking, so always re-price and show the customer any difference.
• A booking succeeds but ticketing fails, so your system needs a clear status and someone who is alerted.
• A request times out, so check whether the booking was created before trying again, or you risk a duplicate.
• Airlines behave differently, especially on NDC, low-cost and baggage content.

4. Build the operations side

Your team needs a way to see every booking, its status and its errors. Decide who handles failed tickets, schedule changes and refund requests. It also helps if someone can check bookings directly in the agent desktop tool when the API and your system disagree.

5. Add your business rules

This is where the integration starts earning money: markups by route or airline, agent commissions, wallets and payment rules. Keep these in your own system and not in scattered code, so your team can change them without a developer. Our travel API integration guide covers this layer in more detail.

6. Pass certification

Travelport checks your integration before giving you production access. In practice, this means:

1. Prepare test scenarios that match what you will actually sell, such as different passenger types and connecting flights.
2. Save the request and response messages from those tests.
3. Submit them for review through Travelport's support process.
4. Fix what they find, then receive your production credentials.

Give this stage real time in your plan. For its SOAP APIs, Travelport asks for at least 15 business days' notice before your planned move to production. On the JSON side, its certification guidance also looks at technical behaviour: refreshing your access token far more often than the recommended roughly 23-hour cycle can count against you unless you have a valid reason.

7. Launch small

Go live with a limited group of routes or agents and watch every booking closely. Check that fares, tickets and payments match. Widen access only when your error rate and support load look healthy.

Mistakes that cost the most time

• Treating test results as production results. Test data and speed can differ, so do not use them to judge live fares or performance.
• Leaving certification to the end. Late findings can push back a launch date you have already promised.
• Assuming every NDC airline works the same way. Test servicing, such as changes and refunds, for each carrier you plan to sell. Our NDC guide explains why this matters.
• Searching too often for too few bookings. Ask how your contract treats the ratio of searches to bookings, then cache sensibly.
• Assuming support will always be instant. Find out what your contract includes, and name a person on your side to manage cases.

Build it yourself or use a partner?

Building in-house makes sense when travel technology is central to your business and you can keep a team on it for the long term, since the work continues after launch.

Using a partner makes sense when you want to reach the market sooner and focus on selling. You still need your own commercial relationship and credentials in most cases, but the partner handles more of the build and the booking platform around it.

Either way, ask who owns your data, who maintains the integration when APIs change, and how you could leave later.

Connect Travelport without starting from zero

Airbytech's flight API integration can bring Travelport content, through your own office IDs, into a flight booking engine or B2B travel portal with your markups and rules.

• See it working: try our live demos
• Plan your setup: talk to our team