The travel industry has a tendency to enjoy bashing itself for everything poor and bad its sees happening, sometimes looking outside to bring a fresh perspective.
But most other verticals are only just scratching the surface about the idea of a world of machines interconnected and talking to each other.
Everyone is now running to open up APIs, thinking they’ll strike gold (users, traffic, sales, etc), just to realize, well, providing an API is not without consequences.
Providing an API means someone else will now depend on your service.
In 2011, you even get Forbes talking about APIs!
Interestingly, the travel industry has been running machine-to-machine communication for decades. It started back in the 1960s with teleprinters on paper tapes and AIRIMP standard messages, up to today’s high-speed links using OpenTravel schemas over the web.
So what can the travel industry teach the rest of the world about its decades of experience with APIs?
1. The obvious: APIs must be well documented, fast, reliable and secure
I am happy to use your great service into my site, but I have many other things to do and can’t spend days reading manuals and trying to make it work. Keep it simple and clear.
I need very few necessary things: what are the input and output parameters, their formats, default and possible values. The best is to give me sample requests and responses and sample codes or libraries that I can start with. Screenshots or a demo site can be nice too.
If I am building a site on top of your API, I need to make sure my site’s performance will not suffer because your API is slow or buggy.
Make sure you’ve run stress test by shooting transactions and simulating peaky traffic scenarios.
I’ll probably require a written Service Level Agreement (SLA) so that we both know what to expect. If I am a big partner, I’ll probably ask you for your stress test results, and I might even have my own teams shoot in some stress tests.
If I am a very big partner, I’ll probably also have my security team attack your platform before I’ll approve it for production. If you already had third party security audits performed, it’s a good sign and it might speed up my decision process.
2. The less obvious: APIs must be testable, measurable and loggable
If I understand how your API works and I trust it’s not going to impact my site, I am ready to¬†integrate it.
I am not perfect, I will have bugs while I develop, and I don’t want to have my infinite loops booking flights for a full week (it has happened).
Please give me access to a test system (or sandbox) I can use to write and test my application without impacting real production environments.
This is an absolute necessity if your service involves locking live inventory or payment transactions. Plan to have test keys, test names and test card numbers available.
In general, I’d like to get a regular (weekly, monthly) report of all transactions I’ve generated, what are the most frequent calls, peak days/hours, total amount of data transferred, uptime, distribution of response times.
Average response time is not good enough: I want to know the response time for 90%, 95%, 99% of my transactions, and how this compares to the¬†Service Level Agreement you’ve committed to.
In case something strange happens in production and we don’t agree about a transaction, I also need you to show me traced logs of the suspicious transactions so that we can understand who’s done something naughty: in other words, my code or your code.
3. The even less obvious: APIs must be supported, “versioned” and maintained
Great, it looks like you’ve got everything we need for a smooth operation. But what will happen in case of production problem? You have to understand that my service could go down completely because of your API.
Are you actively monitoring production status, with scripts testing real scenarios?
If you go down, who do I call? You should have a service center available for your API clients, according to your service quality (24/7 for anything mission critical, less can be acceptable if your service is a minor feature of my platform).
In case of faults, you must keep me up to date as frequently as possible. Use some kind of status notification system, obviously not hosted on the same server.
If everything is under control, let’s go. By the way, now that I spent several days/weeks/months of resources to integrate your service, don’t even think one second about launching a new version and forcing me to redo all the work.
It’s great that you’ll have a new version, but make sure it doesn’t change anything to my current version.
Leave me enough time to migrate, and remember to maintain my version too. A typical migration time in the travel industry is six months from the moment your new version is available, and it’s common to maintain old versions for two years.
Key takeaway: you must be dependable
It’s great to open up your APIs and provide useful data services, but it’s not enough.
If you want your service to be useful and add real value to your clients, you must put yourself in their shoes and literally run for them.¬†If they’re dependent on you, you must be dependable.