APIs are all I think about lately on the Business Development side of the 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, APIs allow companies to expose their backend data and functionality for reuse in new applications.
I wrote previously about 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.
The Current BD Process
- 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 to test it.
- Negotiate the licensing deal.
- Sign the deal.
- Hand off to the engineers to integrate your API.
Some API integrations take months due to customization, testing, and connecting all the technology. 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. 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 find integrations or get distributed.
Types of APIs
Open APIs — An interface designed to be easily accessible by the wider population of Web and Mobile developers (e.g. Yahoo Weather).
Private APIs— An interface that opens parts of an organization's backend data and functionality for use by developers within that organization.
Partner APIs — A hybrid form of the open and private interface models. Usually implemented to support applications built by developers within an organization that has an existing relationship with the API publisher (e.g. Concur, Sabre).
The most important thing that developers look for when consuming an API is the documentation. If the process of implementing and consuming APIs is not well documented, it is less likely to be adopted regardless of the features it provides.
Hackathons
Hackathons are all the rage right now. They're driven by the need of larger travel companies to get close to developers and help sell their APIs. These one-to-two day events help larger travel companies gain insight into what new products and services could be built using their technology, inventory, and distribution power.
The Opportunity: A Global API Marketplace for Travel
Is there a need in the market to build an Open Developer Sandbox and API marketplace platform for the travel industry where:
- Travel companies can search, find, test, negotiate, and license an API deal within days — not months.
- Startups can test APIs from major travel companies in an environment that won't cost them thousands of dollars.
- Large global travel companies can effectively have virtual hackathons running 24/7, 365 days a year.
- Any travel company can set up their own app store like Concur and Sabre to distribute and acquire APIs.
- 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 perhaps 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.
Travel Startups Incubator was interested in investing $25,000 to fund the development of such a platform with the right co-founders, developers, a business lead, and a clear path to monetize. Once the platform was built, we believed we could bring 25 travel technology startups and 2 major travel companies to launch it.
What do you think? What am I not seeing? Where are the technical land mines? Could this business scale?