The Complex and Potentially Lucrative World of Hotel APIs

There is no doubt that there is a lot of money to be made in travel.  Heck, travel (globally) accounts for over 12% of the World's GDP.  That is some serious coin.  You have an incredible idea for a web application that is going to make travellers love you and make you rich at the same time.  The question is... who should I connect with and why?  Here is a quick run down on the pros and cons of connecting with the likely, and not so likely, hotel distribution partners.

First off, I should tell you that there is an organization called the Open Travel Alliance (an organization I Chair) which develops and maintains XML messaging standards that are used by many hotel distribution technologies for the purposes of sharing reservation and content data across the web and other networks.  That said, diving head first into the schemas provided by Open Travel can be a daunting task if you are unfamiliar with the hotel industry to begin with.  Bookmark the site, download the schemas, and keep them handy for when you start integration.

Types of connections

The hotel industry is massive and is made up of three primary layers of possible connectivity partners.  The first layer is large hotel brands like Marriot, Hyatt, and others that have the capabilities to do direct reservation connections.  Only the large brands can do this because they have (generally speaking) homogenous IT infrastructures that allow for reservations to be made across their network of hotels.  The benefit with direct connections to the large hotel brands is that you can negotiate specific contracts.  Be warned however, that the brands probably won't even talk to you if you are a small start-up.  Direct connects are costly and time consuming.

Smaller brands are less likely to have direct connect relationships, which means you are connecting to a switch or GDS.  A switch, such as Pegasus, is a bridge between hotel reservation systems and larger distribution networks further up the supply chain.  A connection to a switch or GDS is generally a little easier to establish and the contractual relationships are a little less onerous but there are still many business requirements that must be taken into consideration.  One important one, for example, is that in order to have a GDS contract you must be a travel agent or authorized travel reseller.  The commissions in this case are usually pretty good, although probably not as good as a direct connect to the hotel.  You will also have to pay for the costs to connect to the GDS or switch including integration and booking fees.

The final connection point is directly into online travel agency hotel booking websites such as, Expedia, Travelocity,, and others.  This is one of the simplest methods and, as a result, one of the lowest paying methods.  Partnerships through these websites usually involve splitting the booking fee or the commission that the online travel agency makes from the booking.  The amount you get per booking is quite low, but the costs of integration, connectivity, and customer service are also relatively low.

Going for Gold

Why not, let's set our expectations really high to start.  We can always whittle them down later anyway.  So if you want to go for gold, you're going to want to integrate in with multiple GDS sources, switches, the OTAs, and hotel brands directly.  If you can do this, and do it well, you will be my hero (not to mention the envy of many travel tech people).  This is the holy grail of integrations, but is a tremendous undertaking and requires that you pull XML data from a variety of XML APIs and web services.  The GDSes, such as Sabre and Amadeus have really nice web services that are available for use.  In both cases, the XML structure is quite close to the Open Travel standard and so there should, theoretically, be some re-usability.  For a complex system like this to work, you would need a multi-tiered approach to API connectivity.

In this arguably simple diagram, I would propose that an Open Travel standard translation layer be added which acts as a mediator between the XML from disparate sources.  The translation layer, in simplistic terms, takes the incoming and outgoing XML and translates it into a system normalized version of the message.  For each new connection, you would need some kind of mapping between the XML from the source and the standardized message set used in the translation layer.  The closer to the standard the incoming XML is, the less work is required to integrate it.  The long term goal, in this structure, is a connectivity framework that needs very little mapping for each new connection made.

The benefit of this type of structure is that it is not dependent on any one XML source.  The downside, as you can probably guess, is the cost and time to put something like this together.

The quick start-up

If you're not going for the full-on Rolls Royce of integrations and you have a small budget for integration then a more realistic approach is to connect to a single hotel online travel agent partner.  There are several that offer nicely documented XML APIs including Expedia/, Travelocity, Orbitz, Hotwire, and Allres.  If you are looking to integrate the full booking experience for your traveler customers, then these are probably your best bet.  If however, you are looking to create some kind of meta-search then your options are even more varied.

When partnering with any one of these travel partners, you will have access to a variety of data, much of which is actually stored locally on your server.  All the hotel data including address, descriptions, links to photos, and locations are provided as data files (primarily csv) that are downloaded and imported into a database structure of your choosing.  For most of the searching, you are left to search against your locally stored database before actually connecting to the OTA for hotel availability and pricing data.  For example, if you are searching for hotels close to you, you would in fact do a query against your locally stored hotel location data.  Your database would return the results and, if so programmed, you would do a subsequent real-time XML query for live availability and pricing for the results that your local database returns.

So, in essence, the OTAs are offloading a lot of the heavy content related queries directly to your website and database while reserving the relatively small availability requests for XML.  The benefit here, of course, is that you get much faster response times from your local database then you would from an XML API (given latency and other connectivity issues) and you have the ability to display and manipulate the data in more creative ways.  The downside is that you have to store upwards of a million or more rows of relational data in your own system AND you need to make sure you have an automated way to update it on a regular basis.

In this diagram, you can see that because we are connecting to a single source for rates and availability, the structure is quite a bit simpler.  The local hotel data in this scenario is the primary source of data for searching and hotel information.  The OTA (online travel agency) XML is the source for rate, pricing, and bookings.  Given a look to book ratio of 50 searches for every 1 booking, the bulk of the load will be handled by the local database.  Your challenge will be to ensure that minimize the look to book ratio and drive travelers to the booking process as quickly and efficiently as possible.

If the direct to OTA model, the bulk of your work and costs will be in the integration of the XML and the design of your interface.  Since the negotiating, contracting, licensing, and customer service is all handled by the OTA partner, you won't need to worry at all about these costs.  Just remember, with this structure, your associated revenues will also be less because you will be sharing a smaller slice of the pie with the OTA.  As you can see, however, this starting structure lends itself well to migration to the next step.  Should you find your mashup growing into a successful model, you can always look to add GDS, switch, and ultimately direct connect relationships in the future.  Kayak, as one example, is really just a massive mashup of feeds from OTAs, GDSes, and airline websites with a really slick price comparison interface, and they seem to be doing alright.

Keep it real

Bottom line, if you're not in the travel industry now and you want to start building mash-ups for hotels, start small.  Pick an OTA partner that offers a well documented XML API and go from there.  Any of the major OTA players will provide the ability to manage the booking on your own website so long as you meet PCI requirements.  If you are providing a meta-search or some kind of simplified search interface, then you can just deep link to the booking process from your interface and avoid the security issues all together.

The travel industry can be a labyrinth for the initiated.  Don't worry about biting off more than you can chew to start.  Keep things simple and focus on what you bring to the table.  Let the booking websites handle the booking, payment, and customer service.  That's the real benefit of hooking up with an XML partner, you get the benefits of controlling the user experience without the need to program a whole bunch of business and distribution logic.

Stephen Joyce is CEO of, a reservation platform for tour and activity businesses. He is the Chair of the Board of Directors of the Open Travel Alliance and a frequent contributor to Tnooz.

Be sure to read the next Travel article: "Car as a Platform" Wars: GM Joins Ford


Comments (2)

"The downside is that you have to store upwards of a million or more rows of relational data in your own system AND you need to make sure you have an automated way to update it on a regular basis."

This made me think of Doctor Evil asking for "ONE MILLION DOLLARS!" It's not exactly intimidating any more.

Very true James. It doesn't seem very intimidating at all. My point however is that this not a pure play XML API integration and does require a fairly sizable database component.