A Brave New World – The Connected Traveler & Travel APIs: Understanding the Legal Realities of Travel APIs Series by Emmanuel Vranakis a technology and startup lawyer.
This blog is part of a series devoted to understanding the legal realities of travel APIs and what it takes to integrate with third party APIs. This series follows on Matt’s blogs last year on travel APIs[i]. The reason behind the series is to explain what the legal issues/risk areas are that travel startups need to cover off when negotiating an API licensing deal.
In this blog, I will be providing a checklist on what the key issues/questions before doing a deep dive on specific areas that need extensive coverage in the next blogs. Parts 2 and 3 will cover Intellectual Property with Part 4 looking at Data (data protection & privacy). I end with Part 5 that talks about what happens when things go wrong.
The Connected Traveller
We are well and truly in the era of the ‘connected traveler’. Research has revealed critical insights on what travelers want from travel companies. For example, a recent survey by the Bio Agency (“Bio Agency Report”)[ii] found that connected travelers do not see their holiday as a series of product touch points – it is their trip and the trip as a whole needs to be as seamless as possible. It must encapsulate the ‘holiday feeling’ from the start and long after return.
Code, data and, API integration’s in particular, are key components in any travel startups/mature businesses strategy to try to reach the holy grail of that ‘holiday feeling’. However, delivering on that vision will take more than just the use of technology and API integration’s to create a connected travel marketplace. We are talking about an experience – technology is only part of the equation. The travel startups/mature businesses that truly manage to pull this off will have a great future and a sustainable competitive advantage.
Setting the scene
The scenario I will be exploring in this blog series is the situation where APIs are only available following the signature of an NDA and API license agreement i.e. Private/Partner. This is different from where a travel startup can start using the API subject to a set of Terms of Use that would be set out on the API provider’s website.
In our scenario, the travel startup will invariably be dealing with a larger company whose approach will often be a ‘take it or leave it’ one when it comes to their API license agreements.
However, even if that is the case, there is a lot that travel start-ups can do to ensure that they are enter into these deals with their eyes open. That is if they know what to look out for and what questions should be asking.
Work starts…
After the euphoria of having signed an NDA, the real business starts when you get the API licensing agreement. Now, exactly when you get API licensing agreement depends from API provider to provider. One of the travel startups I was representing had to wait for about 5-6 months before they got anything and this API provider is a very well-known travel brand. For other clients, it has been faster. The point to take away is it can vary a lot.
From a purely deal-making point of view some API providers are better than others in terms of what contracts they put on the table, knowing what to negotiate and how, being commercial in their approach and supported well by other parts of the business especially in-house legal.
All of these are key variables that will influence the pace of the deal and whether the travel startup gets boxed in a corner and saddled with a whole of raft of risks and liabilities.
Before you get going
Here is a checklist that should structure your approach before you get going with the negotiations.
- What IP assets are covered by the agreement?
- Who owns what IP assets? Both you and the API provider will be bringing IP assets to the table as well creating new IP assets during the agreement.
- What IP assets are licensed, to whom? In the agreement, there will be different licenses given by the API provider to you and you to the API provider covering different IP assets. What do the licenses allow the licensee to do?
- Is the API provider guaranteeing quality of their API, whether they are safe to use, or that they do not infringe somebody else’s IP? Are you asked to guarantee anything? These would be the ‘warranties’.
- Are there any other activities that the API provider prohibits and/or restricts?
- Is the API provider allowed to do any monitoring and auditing you? If so, what does that involve?
- Are they charging you for anything e.g. licensing fees etc.? If so, what and how much? When do you have to pay them?
- Are they paying you for anything e.g. sales you make for them? If so, what and how much? When do they have to pay you?
- What is the deal with information security? What are they asking you to do to make sure that there aren’t any information security breaches? For example, they will probably information security policies and guidelines that you would need to know about to make sure you comply. Can you comply with them?
- What does the licensing agreement say about your customer data? Who is responsible for the confidentiality, security or integrity of such data? Are there shared responsibilities or is it only one way? If customer data contains information that identifies individuals or makes them identifiable, then regulatory compliance is a must do. This is a minefield and the stakes are very high if both parties get it wrong. Another thing to note is that strong data protection/privacy compliance is now a competitive advantage for startups. We will be exploring this in a separate blog series.
- Are there any confidentiality restrictions on both you and the API provider or is it one way? What does confidential information cover and what will you be disclosing to them?
- Are there any restrictions on you in terms of developing products that they think would be competing with theirs? What if they develop products that you think they could be competing with yours?
- Can then the API provider suspend access/use to the API, discontinue or terminate the licensing agreement? If so, when can it do that and how? What happens after that?
- If something goes wrong and it was down to you, what is your financial liability? Is it unlimited or is it capped? If it is capped, are any losses excluded? How much is the cap and does the sum bear any relation to the contract value?
This seems like a lot but we will be exploring these questions over the next few blogs. A final point to take away, is that it is not just a question of just ‘getting on’ with it when it comes with API integration’s. It needs analysis, legal input and ensuring you have covered off any risks. The deal has to be right.
[i] https://www.travelstartups.co/travel-platforms-and-travel-apis-are-the-new-drivers-of-growth-in-the-travel-industry/, https://www.travelstartups.co/an-open-developer-sandbox-and-api-platform-for-the-global-travel-industry/
[ii] http://www.thebioagency.com/media/1411/the-connected-traveller.pdf