Intended audience: Tech personnel and tech-savvy executive staff in the tourism industry.

Just like any other industry, the tourism business also heavily rides on connectivity between many computer systems from a plethora of companies. This means there’s all sorts of custom APIs (Application Programming Interfaces) being used and so each of the “connecting parties” either had to invent an interface to open up their systems to their partners or they had to implement someone else’s interface.

WIthin the tourism industry it’s probably the airline industry that’s most standardized.
A few major players have basically become the de facto standards as they were the first to expose their APIs and due to their size a whole ecosystem emerged around those systems.

The Tours and Activities vertical is much more random.
With over a hundred different booking platforms and way more distribution channels in existence, the amount of one or two-way integrations between the various player represents a cobweb of custom work of different levels of quality.

This poses a massive challenge for these companies as a reliable connection between supply and demand is key to being successful.
Unreliable connections lead to missed orders, lots of manual work to correct failures and trying to restore customers’ faith in the organization. Millions of dollars are being spent on Customer Support departments, discount vouchers, lost income etc. just to salvage the “oopses”.

A good connection between different systems typically comes with quite a high cost of ownership due to:

• The initial implementation
  Lots of programming hours.
• The fine-tuning phase
  More programming due to unexpected situations that come up with day-to-day use.
• Monitoring
  Quality metrics need to be logged and monitored to detect (potential) problems as they happen and avoid a calamity
• Maintenance and updates
  APIs get extended and improved which mean more development work on both sides.
  Let’s just hope you got the work done before the changes become active.

Wouldn’t it be great if there were one standard protocol one could adhere to and achieve instant connectability with one’s business partners?
The answer is a resounding “yes!”.

For all players it is beneficial to have such standards in place.

• SMEs can better interconnect and extend both their catalog (purchasing) and their distribution network (sales)
• The tourist will have a wider range of products to choose from.
  Tourism companies can focus on the gems among a large selection of partnerships, rather than selling the best of the few products they have access to.
• Large organizations can extend their catalogs even further (longtail) as the implementation cost element is off the table.
  Obviously the SMEs benefit from this as well as they now have a fighting change to be included on the big platforms and instantly increase their sales

Early 2019 several medium and large players in the Tours and activities (A.k.a. “Things to do“) got together to define an Open Source API specification that encompasses the functionality they all felt to be the most relevant to their businesses. The idea being that if it covered their combined needs it would do so for most tourism companies.

The result of this was called OCTo (“Open Connectivity for Tourism”). An API specification for a RESTful API defined in the OpenAPI (Swagger 3.0) protocol for maximum adoptability.

It was to be presented at the 2020 Arival event in Berlin which got canceled due to the COVID-19 pandemic kicking off.

Quoting their website:

A list of the companies that is/are participating in the spec can be found on their website.

The unfortunate timing of the COVID-19 crisis (is there ever a good moment?) caused many of the participant to put OCTo on the backburner and the spec hasn’t been publically updated since early 2020.

Nevertheless it is a great initiative for new participants to get in!

Let’s face it. Implementing yet another API for your company will likely result in yet another API that is:

• Similar enough to what’s already out there to be a poor investment of time and money.
• Different enough from what’s already out there to become an hurdle for your business partners to implement.

And if your business partner does the same, multiply the costs by 2.

Their website is a good place to start.
Also reading the specification will help making things clearer to the tech-savvy.

If that’s not enough, feel free to reach out to us!