Sabre API Integration: An Intro Guide to the Top-Tier GDS

Sabre Corporation is currently one of the world’s leading travel data suppliers. Multiple tour operators, online travel portals and agencies around the world are lining up to get a Sabre API Integration as part of their online booking engine or mobile booking app. Thus, this company currently holds a 35% market share in flight bookings alone.

Sabre is a complex organization, which gets even more sophisticated when you dig deeper and get to dealing with it directly. This article is a sort of informative entry guide to help our fellow travel professionals get in terms with this company. The advice and helpful information we share here are based on our long-standing practical experience as a company holding Sabre’s Authorized Developer Partner status. You will learn about peculiarities of Sabre GDS application process, its requirements for applicants, a number of pain points related to the development process, Sabre configuration and more.

A GDS at its finest

Sabre was originally launched by American Airlines in 1960 as a Global Distribution System. Since then, it evolved into a large and established technology platform. Besides acting as a supplier / distributor of airline fares, Sabre is involved in other fields of activity:

• Host / inventory management services as designed for establishing and running fare distribution for airlines;
• Travel automation services via Sabre software solutions. These include a maze of systems handling inventory management, hospitality, data analysis, travel business intelligence, mobile apps, etc.

Thus, a business relationship with Sabre can enhance the company in terms of distribution and overall technological capacity. But let us focus solely on Saber’s airfare distribution service — its most widely known field of activity.

Generally, GDSs form one of the pillars defining the modern travel technology landscape. Systems of this type are designed to act as intermediaries between tour operators / travel agents and multiple travel suppliers. Sabre is currently the oldest and most established of all contemporary GDSs. A connection to this system provides access to the richest source of travel data from:

• 400+ airlines;
• 1.3+ million hotels and properties;
• 40+ car rental suppliers;
• 50+ rail carriers;
• 20+ cruise lines, etc.

The range of valuable travel-related data pieces is enormous, including inventories, schedules, fares, pricing and much more. The automation is set up either via specialized programming interfaces (APIs) for online sales or using manual terminals for offline booking processing.

Sabre Pricing

Pricing is by far the biggest and most frequent concern when it comes to service integration. What concerns Sabre, the prices are considerable and depend on the volume of services a company needs to receive from this provider.

It is important to know that the time-to-market may vary and is hard to predict. But pretty much clear is the fact that it will be based on the following parameters:

• Payment timeframe (meaning how fast you’ll be ready to cover the requested amount);
• Your level of awareness and understanding of the end product you’re planning to build;
• Level of integration of Sabre technology into your project;
• Timeframe to get your IATA accreditation.

Guidelines for Sabre GDS connection process

Being well aware of its dominant market position, Sabre can afford to be very selective when dealing with its customers. This is especially true regarding the API access distribution process. Each candidate has to go through quite a long and tiresome negotiation process, proceeding to the technical side of integration.

Here is a set of guidelines on how to better run Sabre connection process grouped into sections:

Basic business requirements

Any company willing to become a Sabre connected agent must make sure that its business fulfills a set of basic requirements set forth by the GDS.

To begin with, it is necessary to prepare and submit the following:

• Documentation proving your legal business entity;
• A track record of past performance (only applicable for companies which have been around on the market for some time);
• Industry accreditations.

The latter is dealt with in more detail below.

Accreditations

Getting the right accreditation is a major prerequisite to establishing successful relationships with Sabre. The range of requirements here may differ depending on your target market, type of travel product you plan to sell or local legal requirements.

In case your aim is to sell flight tickets, you need to secure either an Airline Reporting Corporation Number (ARC) or a Billing and Settlement Plan identifier (BSP) distributed by IATA. The former is required to sell inside the USA and the latter – in other parts of the globe. Companies which don’t have either of the mentioned accreditation might want to consider operating via a host agency. This is a frequent practice for multiple legal entities to use Sabre connection of a single established organization having all the required accreditations and APIs in place.

Companies focusing on non-ticketing sales might optionally require holding a formal travel industry recognition. It can be ARC’s Verified Travel Consultant (VTC) number or IATA’s Travel Industry Designator Service (TIDS) code. But in this case is also an option to use host agency codes.

In particular situations, companies might need to acquire an accreditation limited to a particular state or country. Some specific areas may force travel businesses to purchase extra permits or bank guarantees for securing both air and non-air bookings. For example, four states in the US have such unique licensing requirements — California, Florida, Hawaii, and Washington. So, it makes sense to run a careful study of travel business regulations in your target location.

Securing your API access credentials

Once you are done with accreditation and basic business arrangements, you get to the phase of getting the required API access credentials. Here, a company usually goes through the following process:

• Filing an application. The easiest way would be to get in touch via SwitchtoSabre.com and fill out a detailed intake questionnaire upon login. Once the form is filed, a Sabre representative will reach out to discuss details about your application and suggest a contract draft.

• Discussion of required API kit and target location. It is important to consider upfront the range of products planned to be sold. The Sabre account you’ll be provided with will be set for specific APIs, products and agreed location. However, if you try to find travel services outside the defined area, you risk getting incomplete results as the search depth is likely to drop.
• Agreement. You are going to receive an online contract version for review. Once you agree with the terms, you’ll be granted access to the management portal, where you can handle the invoices (usually to be paid within 60 days).
• Launching your API credentials. After the payment, Sabre will send your API credentials. There will also be a dedicated account manager that will explain the purpose of all your IDs and keys to work with APIs.

At the moment, Sabre allows a test period for users to try out some of their APIs initially via Dev Studio system. There will be a Test User ID and Password available to sign in to the test account.

Integration pain points: an overview

Once all business aspects are settled we come to the most challenging part – integration. Below is some advice from our tech team on how to better run the integration and avoid hiccups along the way.

Choosing the right API technology

SOAP and REST are the two API versions you can choose from while working with Sabre.

REST style — a simpler and “friendlier” option for engineers — is more popular today as it better complies with the modern web standards. SOAP is more complex and a bit outdated. Nevertheless, Sabre’s catalog shows that the older SOAP method preserves a dominant position: 293 SOAP APIs over only 168 REST APIs.

As for programming languages, PHP, .NET, and Java are more reliable options thanks to productive native libraries available for running SOAP-based integrations. More recent technologies like JavaScript and TypeScript do not have this much out-of-the-box support for older APIs and require lots of custom implementations to work properly.

Booking process implementation

Here we’ll deal with the two most frequent options — flight and hotel bookings.

The flight reservation flow combines several API endpoints to run requests in a defined order:

• A flight search request returns up to 200 flight fares according to the given criteria and sorted by price;
• After a particular flight is chosen from the list, revalidation takes place to check if the option is still valid for purchase at the same price;
• Booking step takes place where a PNR is created. Usually a booking must be paid and ticketed within 24 hours, but this period can be subject to additional negotiation with Sabre;
• Charging a ticket price at the next stage involves retrieving the PNR to track the ticketing queue position. It is a working practice to make the checks every five minutes.

If a company is not accredited for air ticketing, you book flights using your own credentials, while tickets are issued under your host agency ID. This scenario doesn’t impact the integration process very much. But it needs specific settings on the GDS side to allow your host agency to view and change PNRs created at the booking phase.

The hotel booking flow is a bit simpler as no ticketing happens. Here the challenge lies in processing large volumes of textual content and graphics (hotel descriptions, property images, etc.).

For example, images provided by Sabre are often of low quality. It might be a good plan to set up loading of images from other sources.

Changes and cancellations

In order to alter PNR details, it is necessary to use another set of APIs to make the required changes. Then you need to delete certain segments from it, calculate the penalties to be repaid to airlines and hotels, and so on and so forth.

It is frequently reasonable to make changes and cancellations manually. Changes are not too frequent, but do take lots of effort to automate.

New Distribution Capability (NDC)

A few words about this important aspect before we wrap up…

New Distribution Capability or NDC is a relatively new initiative. It represents specific technology for offering content and ancillary services in flight booking.

Sabre holds a Level 3 NDC certificate as an IT-vendor and an aggregator. This certification means that Sabre’s technologies match IATA’s standards and can provide a full scope of services delivered as part of these standards.

A flight-centric supplier that needs to be run by professionals

Even after decades from its launch, Sabre still remains one of the top travel data vendors. This especially true for flight bookings — its original implementation and target market. However, this GDS is also quite strong with other products, especially hotels and accommodations. But this part of the service could really use some improvements.

As shown above, Sabre has a very complicated infrastructure which demands a high level of professionalism to deal with. So it is only logical that the company created a special Developer Partner program to confirm and certify all companies willing to deploy its solutions properly. Running Sabre integration via an Authorized Developer is a smart decision, as this title is only given to vendors with confirmed hands-on experience applying Sabre services on real-life projects.

On the other hand, it also takes an established and reputable travel company to qualify for its very own Sabre API credentials. Working with Sabre directly is truly not for everyone. As the case may be, it makes sense to look at other less demanding vendors — the likes of Mystifly, Travelfusion, PKFARE, — or to connect with a host agency. But anyway, it is still worth the effort getting your dedicated Sabre connection to enjoy some of the best fares and content in the industry.