Stay Connected and Keep Current

Introducing Content Services for Lodging

The new Content Services for Lodging APIs serve more data than ever before. In fact, combining content from the Sabre GDS along with our aggregator partners, provides over a million property options.

That might seem like too much information to handle, but it is surprisingly easy to manage thanks in part to design decisions in the API architecture such as:

• Data normalization
• Shared attribute name taxonomy
• Orchestrated and granular APIs

These features help you control the massive amount of global lodging properties available and keep them from flooding your user interface. Exercise precise control in search requests to surface up the best possible results for your travelers.

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.

Displaying More Options in an Easier Way

We know software developers want choices because we are developers too.

One of the key choices to make is the API protocol. You will find two API protocols to choose from: SOAP/XML and REST/JSON. SOAP and REST APIs are feature-compatible. You will not miss anything by picking the ones that work best for your tech stack and your team’s expertise.

Orchestrated and granular API design is another choice. You may discover that you go for one type of API mixed together with the other type. That is perfectly reasonable. Ultimately, your choice depends on how you want to build your user experience.

The new lodging APIs are built to be stateless. This means that you are not locked-into a particular API workflow. Flexibility to build your application the way you want to is important to us.

You will also notice the APIs introduce several universal identifiers (UIDs). These wrapper and account for all of the potential property options. Searching with the new lodging APIs returns these UIDs:

• HotelCode
• RateKey
• BookingKey

Give these attribute names special attention to become familiar with them because they occur throughout the portfolio of new APIs.

Normalizing Data

Now that we have combined together multiple sources of lodging information you might wonder how they can be consistent? The history of lodging is one that is difficult to compare rates because room information can be expressed differently across several suppliers.

We flatten that apparent divergence by using proprietary machine learning algorithms that shuffles rooms together into the appropriate buckets. When a property option returns from a search request you can rely on it being an inclusive list.

Software using these new lodging APIs will help travel agents stay highly productive in one place. There is no longer a need to open more windows to search in so many places until exhausted. Agents will be able to confidently compare rooms and rates in an “apples to apples” way.

Looking for Common Data Structures

Fully functional shop-and-book workflows can be constructed using the new APIs. By calling them a software application can receive property information, amenities, lead rates, media links, corporate discounts, ratings, loyalty identification, and confirmed room prices.

Everything needed is available to flow into a final booking request.

You will start seeing common data structures repeated by the APIs. Look for them by name and see some of the information they contain:

• HotelInfo – name, chain, hotel code, distance
• LocationInfo – lat/long, address, contact info
• Amenity – an array of amenities
• RatePlan – name, availability, content source, rate key
• RateInfo – dates, currency format, fees, cancel penalties
• Rate – evening date, amount before taxes, current code
• Fee – amount, currency code, description

These common data structures are shared among the orchestrated APIs as well as the granular ones. It is no surprise. The data returned by an orchestrated API conveniently bundles together results from several granular ones. They all share one attribute name taxonomy.

Booking a Property

Shop-and-book is the classic travel workflow. Your software application probably has some variation of it in your user experience. Once you have integrated with some of our new lodging shopping APIs you will need to use one of our core APIs to book.

There are three primary ways to book:

• Create Passenger Name Record – if you prefer a REST-based approach
• Create Itinerary and Update Itinerary – when a SOAP-based approach is better for you

Just as there is a choice in what shopping APIs you use you have a choice when it comes to booking. Pick the booking API that is most appropriate for your application technology stack and your team’s proficiency.

Booking with the new lodging APIs ensures that when you select a lodging from an aggregator it will show up in your traveler’s PNR as an active segment. This gains various benefits like improved duty-of-care, visibility into the end-to-end trip, and incentive eligibility.

Learning with Documentation

Any good consumer product has instructions to help people use it in the way it was intended. APIs need documentation too. Our technical writers delivered high quality reference material for our new lodging APIs to help you get started as quickly and efficiently as possible.

Documentation for our original hotel APIs looked and read like a book. Now we have a set of modern documentation that contains information to help you learn how to integrate our services with your code. It is better structured, contains more examples, and looks the way you expect it to look. Content you will find includes:

• API reference
• Data schema
• Blog articles
• Sample app source code
• Live call capability for REST

We field-tested documentation with developers improving it with every question asked. You should find it clearly describes all of the attributes you want to understand.

Find links to all of the lodging documentation on the Sabre Dev Studio website.

Considering the Future State

We consider these APIs to be ready for production and good-to-go. What is in the future of Content Services for Lodging APIs? Our product roadmap is loaded with even more innovative features.

We plan to include support for more languages as we roll out across the globe. We will add more properties in more countries. Our goal is supporting travel agents as they help their travelers find dream offers.

We fulfill existing demand and want to find novel ways of inspiring travel across the world. People will always want to know how to get somewhere, but that is only a part of their trip. Travelers want to understand what sights and experiences are waiting for them once they arrive. How can we help you help them?

Summary

Designing the new Content Services for Lodging allowed us to bring the industry together to talk about its greatest challenges. We heard first-hand about the complicated realities of travel from the participants of our customer advisory boards.

We have taken feedback and acted on it to ensure we have a fully functional product. Our mission is offering customer-centric APIs that solve real problems.

We will 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. Find the first part of this article already published on the Sabre Dev Studio blog.

This is just the beginning of a much more modern lodging experience from Sabre.