APIs are now widely used across the travel industry so it seems like they’ve been around for decades. In some industries, like finance, they have, but their use is still relatively new for travel businesses.
APIs (which stands for Application Programming Interfaces, and not Advance Passenger Information which is an entirely different thing!) are, as the name suggests, interfaces which communicate with other technologies and which effectively allow content and data to be pulled from one system to another.
In travel, that means travel providers, like airlines, hotels, cruise companies and car hire companies, can share availability and prices more easily and through different sales channels. They can also provide (more) information about ancillary products that they sell, like an offer of more leg room on a flight, or ordering meals in advance at a hotel. This might seem quite simple but was much more difficult through traditional sales channels.
For travel agents and aggregators, APIs can give them access to this extra information from a multitude of different providers allowing them to offer it all in one place and dynamically price accordingly.
For those businesses looking at the legal aspects of APIs for the first time, here are a few top tips to consider:
- APIs are a form of technology but they are not software and shouldn’t be categorised (or contracted for) as such. They need their own form of agreement.
- Saying that, there are a lot of similarities between a software licence and an API agreement. A customer needs to be granted a licence to use the API, and the terms of that use need to be clearly set out – who does the licence extend to, can it be sub-licensed, what does ‘use’ mean? This may be negotiated or may be in a standard form offered by the API provider.
- The API will need to be ‘integrated’, meaning the interface connection will need to be made and then kept live for the data to be pulled (or pushed) through when called. There will need to be obligations on both supplier and customer to make sure the interface is made, tested, kept active and kept secure.
- An API provider is unlikely to give any guarantee as to the security of a customer’s system but it should commit to not introducing malicious malware to the system. A customer may also be able to agree that certain security standards must be met.
- What data is being made available, and can be called through the API, and what rights are needed to use that data? Data ‘ownership’ is a topic on its own which is not covered here but there needs to be certainty on the data that can be called down and what the customer can do with it once they have it. The API provider may not be the supplier of that data and so this question may be one for a different agreement, but it certainly needs to be covered off.
- Consider what promises the API provider gives in respect of service levels or availability of the API. This will depend on whether the connection is a ‘nice to have’ for a customer or whether it is more business critical, in which case something close to 100% availability may be needed. In addition, when thinking about permitted down time, consider the time zones within which the customer and the API provider operate to ensure there is no down time just when it’s needed at the peak of a trading day.
- How does payment and pricing for the API work? Is it a subscription/monthly fee arrangement, or on a per-data call basis, or on a ‘look-to-book’ ratio? Certainly on payment terms is obviously a key factor.
We have seen a myriad of different API agreements and licences and there is no one-size-fits all. The above are common themes we see throughout though and should be on the radar of anyone negotiating one of these agreements.
Authors
Follow us online
