OCTo: Why tourism APIs need to talk to each other

Tours, activities and experiences have come a long way through the pandemic, but our APIs need to start speaking the same language — that’s the purpose of OCTo

It’s not much of a secret that the tours, activities and experiences sector has spent the pandemic playing catch up on technology. Where once walkups, phone calls from a friendly concierge, and a pen and piece of paper were enough, there are now incredibly powerful management, analysis and multi-channel sales platforms that allow providers to optimise every aspect of their business.

These platforms need to be able to talk to each other, and to all the devices connected to them, in order to have any effect. Otherwise, it’s just an expensive spreadsheet that you manually input information into when the concierge calls. The way restech platforms chat is through application programming interfaces (API).

But there’s still a problem. A lot of platforms and online travel agencies have developed their own APIs. This can make it difficult for operators to ensure that all their information is being delivered in the correct way. OCTo aims to fix that.

What’s an API though?

An API is a postman. A postman that works on the internet. A postman that works on the internet at speeds a million times faster than a human postman could even dream of. And they work on request.

The API is tasked with collecting a specific bit of information and returning it to the place that requested it. Requesting the information is named an API call, and returning it is an API response.

If you take out your phone, open the LinkedIn app and pull down to refresh the content, you’ve just made an API call. When the new content appears on screen, you’ve experienced an API response. 

You can also hear calls and responses in an awful lot of songs — the instruments or backing singers respond to the lead’s request. It’s a natural human way of communicating that we’ve built into the internet.

APIs can be complicated little beasts. Each API has to know exactly what bit of information it needs to collect, the server it queries has to know exactly what information to return, and then the app has to know exactly how to display that.

If you look at the code of API, you will see a list of parameters. Each of these requests and delivers that specific bit of information. A simple one may ask for the productName, productPrice, productDate and productAvailability. (Don’t ask me about the naming conventions … :shrugs:)

When these are mapped to a specific section of information in the app and the server everything works perfectly. You can sort it, filter it, search it and separate it out to display it all correctly.

However, problems arise when the API can’t pull the information it wants because it can’t be delivered to the user — error! And when different teams of devs at competing companies in the same industry build their own APIs, they all use different parameters.

Standardisation sounds boring — it’s super interesting

Humans have been trying to standardise everything for millennia. It all starts in the Indus Valley, now part of India and Pakistan, sometime between 3300 BCE to 1300 BCE. They invented weights and measures so merchants could sell things and builders could build things.

But it all really kicked off during the Industrial Revolution. Mass production required everything to be the same. Now, a nut had to fit the bolt used to construct the spinning jenny that spins the yarn into the exact length and weight for the mill to weave into cotton — every single time.

Fast forward a few hundred years and we have national and international standardisation bodies working on keeping the standards. This has spread from the production of goods into services as well.

It’s not just important for the production of goods or services. It’s important for the consumer. I can walk into a bike shop and say that I want this specification of tyres, tubes and brake pads knowing I’ll receive the ones I need to keep me on the road.

APIs in the tours, activities and experiences sector

APIs in the tours, activities and experiences sector are not standardised. This is bad for operators and tourists. OTA A wants to receive its information one way, OTA B in another, and OTA C in a third. Some of the restechs are in on it as well (and some of the good ones are able to handle them all).

That means each operator has to learn how to map every little bit of each of its products onto all of those APIs, and each consumer has it presented to them in different ways. This creates inefficiencies and confusion.

The reason OTAs do this is to try and gain some sort of competitive foothold. Presumably, the thinking goes that if they’re large enough, then most operators will be using their API, it will become the standard and everyone else has to fall into their carefully-laid funnel.

This is anti-business and anti-consumer. History shows that standardisation supercharges an industry. The Indus Valley civilisation became the largest and most dominant of the time and the countries that standardised production the most during the Industrial Revolution became world leaders for two centuries. Both had the most profitable businesses because they allowed them to cooperate and set standards.

The OCTo API aims to fix this

OCTo — or Open Connectivity for Tourism — aims to supercharge the tours, activities and experiences industry by standardising the APIs that every provider uses as their main sales channels. Disclosure: Ventrata is a founding member of the group behind it.

The project has some of the biggest brains in the industry behind it. As well as Ventrata, there’s BeMyGuest, Checkfront, Expedia Local Expert, Peekpro, Redeam, Rezdy, Rezgo, Tiqets, Xola, and Zaui Software. All of us make sure that OCTo meets operators’ exact needs — no matter the business model. And all the work is carried out through volunteering.

In the words of the companies behind OCTo, they have “set their differences aside and worked together to bring the industry a standard specification that allows any system that chooses to adopt the standard to speak the same language and to communicate with each other”.

Everyone in travel knows that no matter how competitive you are with another operator, you’re probably sending each other business. Even the big OTAs are constantly referring customers to each other and skimming a little commission. We thrive on cooperation.

To do so now — to get everyone on the right footing for a post-pandemic boom — we need to speak the same language. To not do so is only holding everyone back.