- Content Services for Lodging Migration Guide
- Content Services for Lodging Deep Dive Part 3: Checking Prices
- Content Services for Lodging Deep Dive Part 2: Getting Details
- Content Services for Lodging Deep Dive Part 1: Getting Availability
- Looking at Lodging APIs Part 2: What You Can Do with Them and Looking Forward
- Looking at Lodging APIs Part 1: Why We Built Them and How You Might See Them
- 6 Powerful Ways Content Services for Lodging Will Change How You Access Hotels Today
- APIs Need Protocols
- 10 Technologies that a Programmer Should Learn in 2019
- September 2019
- July 2019
- June 2019
- May 2019
- March 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- March 2018
- January 2018
- November 2017
- October 2017
- August 2017
- July 2017
- June 2017
- May 2017
- March 2017
- January 2017
- December 2016
- November 2016
- September 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- December 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
Share this page
by Ken Tabor
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:
Give these attribute names special attention to become familiar with them because they occur throughout the portfolio of new APIs.
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?
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.