A leading global distribution system in North America, Sabre leverages content from airlines, hotels, car rentals, and other travel suppliers worldwide. Instead of connecting with thousands of vendors separately, an online booking platform can integrate with just one GDS — and tap into the almost inexhaustible source of information. Sounds like a bargain, doesn’t it?
Our answer is: Yes, but not always and not for all. Read this article, which is based on AltexSoft’s experience as a Sabre Authorized Developer, before diving into the intricate process of integration with the huge and complex platform.
What is Sabre: key things to know
Short for Semi-Automated Business Research Environment, Sabre was developed in the 1960s by IBM to help American Airlines manage its rapidly growing passenger volumes. More than six decades later, the world’s first computerized system for travel bookings still covers a lion’s share of airline and hotel reservations.
Together with its younger counterparts, Amadeus and Travelport, it makes up the Big Three that handles up to 98 percent of the travel distribution market. To learn about the differences between the top GDSs, watch our video.

Sabre vs Amadeus vs Travelport comparison
Sabre and other GDSs act not only as aggregators of travel services. They also provide a wide range of technologies to streamline business operations. Their staple product consists of APIs or application programming interfaces that allow retailers to access the inventory from millions of suppliers and make reservations online. For those who are not familiar with the API concept, we created an explainer video.

How APIs make systems talk to each other
By establishing direct relationships with Sabre, online travel agencies (OTAs), travel management companies (TMCs), and other distributors can benefit from a full set of travel APIs, including (but not limited to)
-
Air APIs for content from 420+ airlines, including 150+ LCCs and 39 carriers with NDC content;
-
Hotel APIs for 2 million lodging options;
-
Car APIs for shopping across 40+ car rental brands in 40,000 locations; and
-
Rail APIs for access to tickets from over 30 rail operators.
Before proceeding to the technical side of integration, a travel company will go into long business negotiations. That’s what we know about the details of this process from our clients and Sabre itself.

Key steps of integration with Sabre APIs
Business negotiations: how to become a connected agent
Pre-integration involves several steps and can take several months, from initial contact to gaining access to most APIs. (You can try some almost instantly, but more on that in a bit.)
Completing basic requirements
If you want to become a Sabre-connected agency, first of all, you must make sure that your business meets the key criteria set by the GDS. To get started, prepare the following information for submission:
-
Proof of legal business entity;
-
Proof of past performance (optional, for agencies that have been operating in the market for some time); and
-
Industry accreditations.
Under the third item, Sabre cites three types of certification.
Accreditations required for air ticketing. To sell flights in the US, you must have an Airline Reporting Corporation or ARC number. For distribution of air tickets outside the US, an IATA number granting access to IATA’s Billing and Settlement Plan (BSP) is mandatory.
Non-IATA/ARC travel agencies have another option — booking flights under the umbrella of a host agency or airline consolidator with all accreditations in place. In this case, you submit info about your host.
Region-specific accreditations. Additional licenses may be necessary depending on your state or country. Some jurisdictions require travel agencies to obtain special permits and provide security bonds or bank guarantees to sell air and non-air travel services. In the United States, four states — California, Florida, Washington, and Hawaii — have their own Seller of Travel (SOT) laws and licensing requirements. Always check local regulations before starting a travel business.
Non-ticketing accreditations to prove industry recognition (optionally). This includes ARC’s Verified Travel Consultant (VTC) number and IATA’s Travel Industry Designator Service (TIDS) code, which is now free of charge. You can also use the codes of your host agency.
Getting access to APIs
When all required information is collected, your next step will be roughly as follows.
Completing the intake form. The most straightforward way to initiate interactions with the GDS is to complete an online form on the Contact Us page. You’ll be asked to provide information such as your company website, IATA/ARC number, and current annual booking volumes. Upon completion, a Sabre representative will contact you to review your request and prepare a contract that meets your needs.

The fragment of Sabre's intake form
Negotiating an API set and target location. Your Sabre account will be pre-configured for particular APIs and locations you’ve agreed upon. If you target North America, you’ll get access to the latest information on bookings from this region. But once you try to find travel products outside the defined area, the depth of search will drop, and you will be at risk of receiving incomplete and/or outdated information. So, think over what and where you're going to sell beforehand.
Signing a contract. The commercial contract covering scope, liability, pricing, and usage terms is usually sent via DocuSign, a transaction platform that enables you to securely finalize deals online. Take your time to consider price options and discuss the agreement with your lawyers. If eventually you are fine with all the terms and the contract is signed, Sabre grants you access to their account management portal, where you can find invoices to be paid within 60 days.
Getting credentials. Once all formalities are complete, you’ll be connected with a dedicated Sabre account manager who will guide you through the setup and ensure you receive all necessary credentials. These include:
-
a Pseudo City Code (PCC) or an Internet Pseudo City Code (iPCC) — alphanumeric identifiers that define your organisation’s permissions, geographical coverage, and assigned Sabre environment. The PCC grants access to Sabre Red 360 (the travel agent desktop) and Sabre APIs, while the iPCC is typically issued to OTAs for API-only use;
-
Employee Profile Record (EPR) — an individual profile linked to a PCC or iPCC. It determines what actions the employee can perform within the Sabre GDS;
-
Client ID — a unique signature generated for customer applications consuming Sabre APIs. It allows Sabre to track service usage by specific programs; and
-
Client Secret — a private key that controls who can use the Client ID..
Although the Client ID and Client Secret are optional in most cases, Sabre recommends using them — especially for agencies sharing the same PCC across multiple platforms. These credentials allow both Sabre and developers to monitor performance and optimize application behavior.
Adding new APIs and regions to your shopping cart. Keep in mind that each time you want to integrate with an additional API or cover a new region, you must contact your account manager, make amendments to the agreement and wait for the account and access to be re-configured. The entire process can take a couple of months.
It’s worth noting that Sabre lets you experiment with some of its APIs without any prior negotiations. Simply create an account in Sabre Dev Studio to obtain test credentials and access publicly available REST APIs in a sandbox or try-out environment. This allows for quick prototyping, exploring API responses with mock data, and testing your integrations. However, to move further, you’ll need to formalise your relationship with Sabre.
In addition to signing a contract, you’ll also need the right team to execute the integration project. You may already have experienced developers on board, but if not, let’s explore where to find suitable specialists.
Talent acquisition: how to find the right developers for Sabre API integration
When it comes to Sabre integration, it doesn’t matter much what programming language your engineers master. The platform supports almost all popular technologies. Specifically, AltexSoft developers used Java and TypeScript.
The two key qualities to look for in developers are understanding APIs and domain expertise. Your ideal candidate should have a solid grasp of such specific travel concepts and processes as
-
many other industry-specific concepts.
And here we come to the winning combination of API and domain prowess you can acquire if engaging developers who have already participated in GDS integration — at least once.
You can find experienced teams in the Developer Partner Directory, which lists only Sabre-certified companies. Partnering with them ensures a faster, smoother integration process, as their engineers are already familiar with the platform’s intricacies.. “With accredited vendors, a client avoids paying extra money for errors and a long learning curve, inevitable for newbies,” Andrii Chebotarov, Managing Director of Travel and Transportation at AltexSoft, argues. “Besides that, the right architecture will be laid from the very beginning, so the quality will be better as well.”

Andrii Chebotarov explains travel distribution technologies
Sabre API integration: what to expect
So, you’ve signed a business contract and your development team logged in to the Sabre certification or testing environment. Hold onto your hats, because you’re proceeding to the most сhallenging part.
As Glib Zhebrakov, Java Competency Lead at AltexSoft, puts it, “A Sabre Developer is one who has already gone through the challenging process of Sabre integration.” Here are some takeaways from our previous experience that may help you in your integration journey.
Choosing between SOAP and REST APIs
You can interact with Sabre content via two prevalent types of APIs, SOAP and REST. But which one to use? The developer-friendly REST style has become the most popular option today due to its relevant simplicity and compliance with modern web architecture. SOAP is considered more complex and archaic. However, with Sabre, the choice is not that obvious.
Even a quick peek into Sabre’s catalog reveals that the older method maintains a dominant position: 242 SOAP APIs vs 175 REST APIs. AltexSoft developers point out that the GDS provides elaborated SDKs (software developer kits), facilitating SOAP integration, which is not always the case with REST APIs.
Though we’ve mentioned that the choice of language isn't that important, PHP, .NET, and Java developers get the better hand since there are good native libraries to establish connections via SOAP. “Younger technologies like JavaScript and TypeScript don't enjoy such a level of out-of-the-box support when integrating with old-style APIs, so many steps require a custom approach,” Ivan Mosiev, Solution Architect at AltexSoft, explains.
Getting a helping hand
When you first enter the Sabre universe, you may be confused or even shocked by its complexity. It’s hardly a surprise, though, given that the platform handles thousands of carriers, hotels, OTAs, and other players.
Of course, there is documentation created to assist newcomers with typical issues. However, some problems haven't been addressed yet.
“You may catch mistakes that haven’t been documented. You’ll have to do a few things by trial and error and often contact Sabre support,” Ivan Mosiev recalls from his acquaintance with Sabre. It may take several hours to several days to process your request. You can also ask for help on Stack Overflow, which already hosts almost 650 Sabre-tagged questions.
Creating the right requests
Shopping requests for travel products are bulky, and it takes you a massive amount of time to arrange them properly. They contain a number of fields to be filled out in a specific way, so that you can get relevant offers — or content supplied by travel vendors in response to your request.
For example, when working with flight requests, you need to figure out how to exclude or choose certain airlines, how to sort out origin, intermediate, and destination airports, and consider many other details.
The same goes for hotels. “I wasn’t new to SOAP," Glib Zhebrakov shares about his experience with the GDS. “So, for me, there was nothing puzzling about API requests per se. The problem was in Sabre-specific peculiarities you just couldn’t know about if you’d never encountered them before.”
Automating flight booking flow
The full-fledged flight booking flow involves the implementation of several API endpoints to make requests in a particular order.
-
Flight search. The request returns a list of up to 200 flight offers that meet our criteria and are sorted by price.
-
Revalidation. After a particular flight is chosen from the list, you need to check if this option is still available and valid for purchase at the same price.
-
Booking. At this step, a PNR is created. By default, the booking must be paid and ticketed within 24 hours. Yet, this aspect can be negotiated with Sabre separately. For example, one of our OTA clients took advantage of a 48-hour time window.
-
Charging a ticket price.
-
Ticketing and retrieving the PNR to track where you are in the ticketing queue. Usually, we set the system to make checks every five minutes. If, after the fifth check, your e-ticket is still not ready, a travel agent has to be involved and complete the step manually.
- Ticketing and retrieving the PNR to monitor your place in the queue. Typically, we configure the system to run checks every five minutes. If, after five attempts, the e-ticket still hasn’t been issued, a travel agent must step in and complete the process manually.
Watch our video to better grasp what the end-to-end flight booking consists of.

Flight booking steps and key systems
If your OTA isn’t accredited for air ticketing, you’ll book flights under your own credentials, while ticketing will be handled under your host agency’s IDs. This setup doesn’t significantly affect the integration process but does require specific GDS configurations to allow your host agency to view and modify the PNRs created during booking.
Automating changes and cancellations
What about changing travel details or handling cancellations? To support these scenarios, you’ll need to implement an additional set of APIs that can modify PNRs, remove specific segments, and calculate any penalties owed to airlines or hotels. The process becomes even more complex when only one flight leg must be cancelled while keeping the rest of the itinerary intact.
Because such cases occur less frequently than standard bookings, many OTAs choose to process changes and cancellations manually via the Sabre travel agent portal. Automating these less common workflows can require substantial development time and effort.
Automating hotel booking flow
The hotel booking flow is generally simpler since it doesn’t involve ticketing. However, it comes with its own set of challenges. Flight offers usually contain minimal text and no images, which is expected. But when travelers search for hotels, they expect detailed descriptions and high-quality photos of the property.
GDSs still lag in delivering feature-rich content. This is because they mostly target travel management companies when offering hospitality inventory, and rich content remains a lower priority for corporate travel. If you want your customers to see hotel rooms in all their glory (and finally book them), you often have to upload photos from other sources. Check our article on hotel APIs to learn more about hospitality suppliers.
Taking advantage of API workflows
In some cases, you can accelerate the development process by utilizing API workflows — predefined sequences of API calls documenting how to implement certain processes end-to-end. Here are several available options.
Air booking. The sequence covers three steps of the traditional flight booking flow.
-
Search for flight options sorted by the cheapest fare
-
Validate the availability and pricing
-
Book (generate a PNR).
The second API can be used to request additional details, such as seating, flight details, or fare rules.
LCC booking. This workflow streamlines the process of sourcing and purchasing flights from low-cost carriers (LCCs). In addition to searching and booking flights, it enables you to add passenger details — such as email, travel documents, and payment information — and to buy ancillaries like baggage and seat options before completing the reservation (ticket issuance).
The same process applies to any LCC that partners with Sabre — for example, Ryanair, easyJet, or PLAY Airlines.

LCC booking flow with ancillaries. Source: Sabre Dev Studio
NDC booking. This end-to-end workflow is designed for tapping into New Distribution Capability (NDC) content. It lets you shop NDC fares and ancillaries, create NDC orders, and service them after the reservation is completed. The post-booking stage allows you to automate operations such as:
-
adding or modifying passenger data,
-
displaying seat maps,
-
adding or deleting ancillary services,
-
reshopping itineraries and exchanging tickets, and
-
cancelling entire orders.
This is by no means the full list of available functions. As Sabre continues to expand its partnerships with NDC-enabled airlines, the range of supported features is constantly growing.
Other commonly used workflows include issuing traditional tickets and handling their post-booking servicing, adding ancillaries and creating an electronic miscellaneous document (EMD) for air extras, as well as managing car and rail reservations.
Certification: when your integration can go live
Your API implementations may be fully tested and seem ready for launch — but that’s not the final step. Before switching from simulated to live data, your integrations must undergo Sabre’s certification process.
During certification, Sabre specialists access your test environment to ensure that each API request and response sequence behaves correctly — in other words, that the entire travel-shopping flow performs as intended.
The certification phase usually lasts four to eight weeks, so make sure to account for it when planning your time-to-market. Once you successfully complete this step, Sabre will issue your production credentials, allowing you to start live operations.
Key lessons learned: it’s hard but worth the effort
Now that you see the complete picture, we want to sum up by highlighting important aspects.
Sabre is flight-centric. Sabre was designed primarily for air ticket distribution, and that’s where it performs best. Challenges appear, however, when it comes to hotel booking. The content retrieved is often far from ideal: expect low-quality property photos and tiny 200×200 px hotel logos. In the era of high-resolution Retina displays, this clearly leaves room for improvement.
Your developers should clearly understand how flight booking unfolds behind the scenes. Knowing the exact sequence of requests is extremely helpful — it speeds up navigation through API documentation and makes it easier to get precise answers from technical support.
It’s a long-term initiative. Sabre integration is a long process, from both business and technical perspectives. It can take anywhere from several months to a full year, starting with the intake form submission and ending when your project goes live.
GDSs are still an unrivalled option for those who sell air travel at scale. Sabre enables you to retrieve offers from hundreds of airlines and automate the entire booking flow. Ultimately, the effort invested in integration pays off.

