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.
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.