API’s are all I think about lately on the Business Development side of work I do for the startups in our portfolio. Every startup is either looking to distribute their API or acquire an API from a 3rd party travel company.

For our investor friends and non-techies in its simplest terms API’s allow companies to expose their backend data and functionality for reuse in new applications. For example the Flitways API allows airline developers to build a ground transportation application that can display all of Flitways 15,000 vehicles and pricing in a city/destination when a traveler is booking a trip, without having to store and maintain the real-time inventory and pricing data.

A few months ago I wrote Travel Platforms and Travel APIs are the NEW drivers of growth in the travel industry.

The business development sales process is somewhat repeatable when looking to commercialize and get distribution for your travel API.

  • Find the correct contact person at a travel company.
  • Email or call that person.
  • Send your 5-page API pitch deck highlighting how the company will benefit by licensing your API.
  • Explain how the company will make money with your API.
  • Receive a request to view your API documentation.
  • Sign an NDA.
  • The company places your API in their sandbox so they can test it out.
  • Negotiate the licensing deal.
  • Sign the deal.
  • Handoff to the engineers to integrate your API.

Some API integrations take months due to customization, testing and connecting all the technology. I understand this but finding the right API for your business needs, connecting with the right person and testing the API should take a few days, not weeks or months. I mean we are in the travel technology business after all.

My hypothesis is that there are over 1,000 travel APIs right now in the market trying to either a) find integrations or b) get distributed.

Open APIs
An open APIs is an interface that has been designed to be easily accessible by the wider population of Web and Mobile developers. (e.g.: Yahoo Weather)

Private API’s
A private API is an interface that opens parts of an organization backend data and functionality for use by developers working within that organization (e.g: API’s used by Apple, MSFT etc. that shows similar features across different application made by the same company.)

Partner API’s 
A partner API is a hybrid form of the open and private interface models. This kind of API is usually implemented to support applications built by developers within an organization that has an existing relationship with the API publisher. (Concur, Sabre)

Few other points
This most important thing that developers look for when they consume an API (except private API’s) is the documentation. If the process of implementing and consuming API’s are not well documented then it is less likely to be adapted regardless of the features it provides.

The proliferation and demand for quality travel content is only growing. Concur and Sabre built entire departments and new revenue verticals around APIs and app stores. There are major travel companies preparing to build their own app stores, platforms and sandbox testing grounds.

Cozy up to the developers (the creators).

Hackathon’s are all the rage right now. Tnooz held one in Berlin in March, one in Seattle in April and have one in Dublin this weekend. Kayak held What The Hack in late April. You name it everyone is getting into the hackathon business.

Hackathon’s are driven by the need of the larger travel companies to get close to developers and to help sell their APIs. Hackathon’s one-to-two day events help the larger travel companies gain insight into what new products and services could be built using their technology, inventory and distribution power.

The developers and entrepreneurs get to tinker, create and maybe come up with something innovative and a real breakthrough. It’s a win-win for each party involved.

Is there a need in the market to build an, Open Developer Sandbox and API marketplace platform for the travel industry where;

  1. Travel companies can search, find, test, negotiate and license an API deal within days not months.
  2. Startups can test APIs from major travel companies in an environment that won’t cost them thousands of dollars.
  3. Large global travel companies can in effect have virtual hackathon’s running 24/7 365-days a year.
  4. Create a marketplace where any travel company within any vertical can literally setup their own app store like the likes of Concur and Sabre to distribute their APIs and to acquire APIs.
  5. An open marketplace exists so both developers and travel tech companies can meet, communicate, test and license APIs.

I see multiple business models for a global API travel platform. Subscription-based, transactional and maybe even corporate sponsored. If the marketplace platform brought two travel companies together we could sit in the middle and take a small % of every transaction for facilitating the licensing deal and helping establish the new business relationship.

The Open Travel Alliance is a comparison I see to the API platform idea even though the alliance is really about establishing technology standards and structures for electronic messaging, enabling travel suppliers and distributors to talk the same language.

Drew Meyer’s oheyworld.com is an open sourced platform (user accounts, locations, social graph, city searches, and information tagged to those cities) that could be a great starting point for anyone to build B2C or B2B integration.

Programmableweb has a list of 134 travel APIs but this is just a directory listing and it seems as if it doesn’t get updated much.

Travel Startups Incubator is interested in investing $25,000 to fund the development of such a platform with the right co-founders, developers, a business lead and clear path to monetize. There is obviously much more thinking and strategy that would need to be applied but I hope I have sparked some initial interest.

Once the platform was built I believe we could bring to the table 25-travel technology startups and 2 major travel companies to launch it.

Thanks to Madhu Madhusudhanan the founder of Proxce for contributing technical context to the article.

What do you think?
What am I not seeing?
Where are the technical land mines?
Could this business scale?
How big could it be?
Who wants to build it?


Feedback I have received via email so far. Looks like some commercialization and funding issues.

1) Startups are generally broke and/or won’t pay much for data.
2) Data suppliers into existing APIs don’t allow reselling of data because of contracts and/or policy.
Mashape has a API marketplace. It’s broad based but it looks like they have a model to monetize.