6 years ago

Open call to all travel companies: Simplify your APIs!

First things first, as chair of the OpenTravel Alliance, I am a staunch supporter of open APIs and standards in travel.

So, inevitably, I was certainly happy to see a large number of presenters at this year’s Travel Innovation Summit at the PhoCusWright conference talk about having their APIs available to third parties.

In my experience though, most of these APIs will see very little in terms of large scale integration.

You don’t have to look much further than the Programmable Web directory to find that there are, already in the market, close to a hundred APIs tagged as travel.

There are also about 490 mashups (sites that integrate one or more APIs) that are considered travel-related.

I would argue that many of the innovations presented at the Innovation Summit, especially the social trip planning ones fall under the heading of mashups, combining travel apis from Expedia, Hotwire, or Orbitz along with the Facebook OpenGraph, Google Maps, or other non-travel related APIs.

Some innovations, like FlexTrip, are meta-aggregators of APIs, combining many different feeds primarily from tour and excursions providers like Viator, Urban Adventures, TourCMS, Rezgo, and others, normalizing the content in a local database and then displaying the content in a unified homogenous manner.

In the case of FlexTrip, it is even providing an API to its own aggregated content which, when you think about it, is one big pipe that is fed by many smaller pipes.

One of the big complaints with travel APIs, however, is that they are complex and cumbersome to use.

Many of the larger, more powerful APIs require commercial agreements and most, if not all, have documentation and support that is hidden behind corporate portals.

In essence, the big gatekeepers of data make it tough to use their data.

One example of how simplifying an API can increase adoption is to look no further that Google Maps. Out of all the mashups listed on the ProgrammableWeb directory, the most prevalent API used is the Google Maps API with 2,309 mashups.

The next most popular API is Twitter with about 653 mashups.

So, why is the Google Maps API so popular? Because the API is incredibly simple to use, easy to access, fast, well documented, and supported by a large community of users.

In a more vertically specific example, we saw, at the THack Boston earlier this year, Amadeus (which has listed its APIs on Programmable Web) release a mini-API for hotel search that was very simple, light weight, fast, and easy to access.

For that event, it was the most used API, not because it was the most powerful or provided the most data, but because it was easy to implement.

At the end of the day, there are more great ideas and clever developers to implement them than there are APIs to support them.

Many of the most successful travel innovations have been built on APIs.  You need not look further than Kayak or the more recent Hipmunk to see that tapping into data and adding a layer that makes it easier for consumers to manipulate that data can be a successful model.

But these success stories are few and far between when you consider the number of potential success stories that are out there.

To all those innovators out there, including the existing legacy travel technology providers, I say the following:

Take a close look at the data that your company has locked away and think to yourself whether or not there may be some value in making some of that data available through an API.

You may even find that others are willing to pay for access to that data if it is compelling enough.  In addition to making your data accessible, look to organizations like OpenTravel to provide messaging structure and support.

Who knows, some clever developer out there may do something amazing with your data that you had never considered before.

Those discoveries and sparks of genius can only happen if you’re willing to support it by opening up and simplifying access to your content.

NB: Image via Rumpleteaser on Flickr.

Share on FacebookTweet about this on TwitterShare on LinkedInEmail to someone
Stephen Joyce

About the Writer :: Stephen Joyce

Stephen Joyce has been a contributor to tnooz since 2009 and has been working in travel and tourism technology since 1995. Stephen is the CEO of Rezgo.com, a cloud based software as a service reservation and booking platform for tour and activity providers.

Stephen is the Past Board Chair of the OpenTravel Alliance and currently sits on the Education Advisory Group for the National Tour Association (NTA).

Stephen is a graduate of Capilano University, a certified commercial pilot, and holds a certificate in IT Management.



Your email address will not be published. Required fields are marked *

  1. Open APIs in travel need to grow up – - API MarketingAPI Marketing

    […] support innovation and satisfy consumers, as Stephen Joyce points out in an earlier Tnooz post, APIs need to be open and fairly simple to use (and I would add scalable, but that’s another […]

  2. GDS news from Travelport, Amadeus, Sabre, Abacus - December 2011 | Tnooz

    […] Open call to all travel companies: Simplify your APIs! […]

  3. Open APIs in travel need to grow up | Tnooz

    […] support innovation and satisfy consumers, as Stephen Joyce points out in an earlier Tnooz post, APIs need to be open and fairly simple to use (and I would add scalable, but that’s another […]

  4. Régis

    Hi stephen
    Thanks for this article…
    Being a user of amadeus api for a long time, i’m interested in the news you gave about their new mini-API.
    Do you havesome more information on this?
    thanks a lot

  5. Tony Carne

    Thanks for the mention in your article Stephen and Alex thanks for the validation that Urban Adventures is on the right track with its API.

    The timing of this article is quite uncanny as we’ve just revised our documentation (literally yesterday) that goes with our API . If anyone would like to see the updated version, please don’t hesitate to get in touch.

  6. Matthias Scheffelmeier

    Dear Stephen,

    thanks for your great post!

    To us at pocketvillage, yet another API provider sourcing its content and offers from a dozen of tour and activity APIs (or as you put it so nicely “a pipe fed by many smaller pipes”), simplicity is among the top priorities, but we’d like to add one more thing, which we believe is even more important: Integrability.

    An easy to use API with a large quantity of different offers is nice, but every website and every user is different. We believe that for API providers and even more so for meta-aggreators of APIs enhancing the data with additional information (categorizing, tagging, filtering it etc.) makes all the difference, since it will allow you to integrate the API in various ways.

    Say you’re the manager of a flight & hotel search and you’d like to cross-sell activities and tours, but the only data you get is the name of the activity, the city where it takes place and its price – though you’d know much more about your customer (where he goes, how old he is, where he stays, with whom he travels) you can’t really make use of that info unless the data you have at your hands is rich (rather than just simple to use).

    And that is especially true for the tours and activities market where you have an amazing amount of different offers out there and hundred thousands of individual needs and wishes from your customers.

  7. Alex Kremer

    Thanks for the Flextrip mention Stephen and we obviously agree the simplification of APIs will benefit the industry as a whole.

    I’d just like to offer a quick comment that we think that a lot of Tours & Activities APIs are actually very technically sound vis-a-vis a lot of other industry segments. All of the T&A API’s you mentioned by name are great to work with and we think the value Flextrip adds is more on the delivery side than the unification side. Each of the providers we work with has put a lot of hard work in acquiring content, so that is not to be overlooked.

    That being said, there are some legacy APIs in other industry segments that are, from a technical level, cringe-worthy. I think those with difficult APIs would be wise to heed the words above and, dare I say it, would see increased sales and adoption.

    • Stephen Joyce

      Stephen Joyce

      I would agree with you. Because of the relative age of the technology in the T&A segment, I think we have a better idea of how to a) make data available b) structure simple messages to support sharing. These also tend to be applications or services that have grown up online.

  8. Kevin O'Sullivan

    Stephen – what is OTA doing to simplify its schemas?

    • Stephen Joyce

      Stephen Joyce

      This past year, OpenTravel has been focused on a project referred to as OpenTravel 2.0. The project is designed to allow the creation of lean messaging. Many of the legacy messages are quite heavy but primarily because they are one message fits all type structures that have had new fields added to them continuously over 10 years. The new model is to create purpose built messages based on a standard syntax. Some of the new messages such as the tour/activity and golf messages are being built using this methodology.

      • Kevin O'Sullivan

        What is the timeline on Open Travel 2.0 – when will it be ready for use?

        • Stephen Joyce

          Stephen Joyce

          The OpenTravel 2.0 prototype structures are already being integrated into messages that are being released in the 2011B messages which are due out this month. Feel free to contact Bonnie at OpenTravel or send a tweet to @opentravel for more specific details.

  9. Chris Clarkson

    So what you’re actually saying is more companies should make APIs available?

    Simplifying API’s is an entirely different conversation. Google Maps API is a very simple API at it’s base use, as it’s a fairly simple product.

    • Stephen Joyce

      Stephen Joyce

      You’re right Chris, it’s a two part conversation. First part is to make data available, the second part is to make sure it is made available in a relatively simple fashion.

  10. Alex Bainbridge


    Another call would be for APIs to support business and access models the API designer didn’t originally envisage…….. as that provides the greatest platform for innovation. For example many travel product APIs are designed in such a way that they infer that they are for making new bookings only – when I can think of many uses of a travel product API that may not directly (but will indirectly) lead to new bookings.

    • Stephen Joyce

      Stephen Joyce

      That’s a great point Alex. I think this is the biggest challenge for legacy systems whose APIs are specifically designed around bookings or availability searching. There are so many other interesting things we can do with the data.

      One really interesting example from the ProgrammableWeb directory is a Google Maps/Amazon Affiliate mash-up that shows you books that have been written that are based in the destination that you are visiting or interested in. So, for example, if you were in Forks, WA, the mash-up shows you the Twilight series.


Newsletter Subscription

Please subscribe now to Tnooz’s FREE daily newsletter.

This lively package of news and information from Tnooz’s web site provides a convenient digest of what’s happening in technology that drives the global travel, tourism and hospitality market.

  • Cancel