Stay Connected and Keep Current

Introducing Content Services for Lodging

Sabre offers a suite of new APIs called Content Services for Lodging. They help you shop and book properties that meet your travelers’ needs. By using the portfolio of APIs your software application can:

• Shop room rates and availability supplied from hotel chains and aggregators such as Booking.com, Bedsonline, and Expedia Partner Solutions offering over a million property options
• Read detailed information including location, amenities, contacts, ratings, lead price, and display-ready images
• Confirm selected pricing offers, in a chosen currency format, are the latest ones available from our supply sources
• Book using convenient, stateless, identifiers linked to a shopped property

I had the honor of speaking to several of my Sabre colleagues involved with the new API development. What I learned from them is captured below.

Solving Hotel Fragmentation

Sabre has an existing hotel API offering that you might be using. These APIs were built many years ago with data coming from a single source. They were designed for a different travel environment than what exists today.

Back then we found that travel agents had a deep understanding of what properties exist and there were only a few ways a traveler could book a hotel. Now there are millions of options in the world and multiple ways it is distributed. Choice is great, but it does make it challenging to find the right options for your traveler to make the best offer.

The travel landscape has evolved.

Our goal is empowering a travel agent who does not have an expert knowledge of locations and their amenities and what is available for shopping. We want to make it easier for agents to discover properties matching their travelers’ needs and their company’s preferred rates. We understand that the number of properties offered by suppliers has skyrocketed. Customers have a much wider variety of choices. It is important to return the right shopping results on time.

Now you will find the Content Services for Lodging APIs offer over a million property options from many content suppliers. When you review a “room with a king-sized bed” from multiple sources you can be sure you are making a “side by side” comparison and your traveler will truly understand the value of a rate.

The best part of it all? Booking with one of the aggregators in Content Services for Lodging generates an active segment in your traveler’s PNR.

Considering SOAP or REST and Orchestrated or Granular

Reinventing our APIs allowed our product managers, architects and programmers a chance to make new choices in the tools and techniques they use to build services. Modernizing the technology powering our APIs makes us efficient, able to deliver frequently, and introduce new API choices.

One of these choices includes how the APIs are designed. You will find two API protocols to choose from: SOAP/XML and REST/JSON. Both sets of APIs are feature-compatible. Pick the ones that work best for you based on your application technology stack and your team’s proficiency.

Another choice that you have is in the architecture of the APIs: orchestrated and granular. You can choose to go all orchestrated, all granular, or mix-and-match them. How you choose is based on what is best for supporting your user experience workflow.

Orchestrated APIs are most helpful when your software application has a typical shop-and-book workflow. Orchestrated APIs take advantage of a number of granular ones to bundle together a collection of content for you in a single API call. You might find this convenient because it reduces the complexity of your source code.

Get Hotel Avail V2 is an example of an orchestrated API. Some of our team considers it to be a “flagship” API because it delivers so much power in a single request. It pulls from a variety of sources, supports search criteria, filters, picks the best rates, provides image content, ratings and more.

Using granular APIs is an advantage when you have a different type of user experience with distinct needs. Think of these as “ala carte” tools that you can reach for when solving very particular problems. You will notice there are more granular APIs than orchestrated ones because they return specific information.

An example of a granular API is Geo Search. Its new capability allows searching based on a polygon shape. A concrete example of this is drawing a rectangle around a section of a downtown city in which your traveler wants to stay. Traditional radial searching can catch too many results as compared to the precision of polygons.

These APIs are designed to keep attribute names consistent across requests and responses. Data structures are shared between APIs making them more easily recognized as you work with them. In the past, lodging data was simple blobs of text. Now data is highly structured improving ease-of-use.

Because the APIs are stateless, and respond with unique identifiers (UIDs), you can casually switch between orchestrated and granular APIs. This opens up flexibility in the way you might use the new lodging APIs. UIDs ensures your code is not tied to any particular sequence of events. It also means that content from all suppliers is dependably tracked in a unified manner.

Sabre development teams made these design choices in the service of providing a fantastic developer experience.

Reading Normalized Data

Many lodging properties are carried across multiple supply sources. We see that each supplier can represent a given property in a different way. While this can make a property appear to be unique, it is in fact the same room and location, but with a slightly changed definition.

That makes comparison shopping difficult.

Normalizing data means that we can help travel agents feel confident that they are reliably comparing the same offer based on amenities and price across all content sources. Normalization reduces confusion and enables good choices based on true value. You will also find that it simplifies shopping results.

Without data normalization you might see the same property come up looking like five different properties. That is a problem when they all refer to the same one, but with slightly unique descriptions. We found this is a typical challenge for today’s travel agents and we want to help make it better.

Learning the New Lodging APIs and Future Updates

We offer many resources that you can use to learn how to integrate with the new Content Services for Lodging APIs when they are launched June 24th.

Visit the Content Services for Lodging APIs main page on Sabre Dev Studio to discover more information about schemas, references, and guides.

We will also publish a series of sample app source code demonstrating how to use the three-main orchestrated APIs: Get Hotel Avail V2, Get Hotel Details, and Hotel Price Check V2. Look for those to be published on the Sabre GitHub account from the end of June through the beginning of July.

Look for the second part of this article on the Sabre Dev Studio blog. It will go into more depth on what it looks like to call the APIs in code.

With the help of our customers’ feedback we have learned, prototyped, tested, and delivered on what our travel agency customers need from Content Services for Lodging. That includes more lodging content options, enhanced shopping and booking, and the convenience of offering all of that information through a single display.

There is more to come – our product roadmap is loaded with features!