In one of my most recent post titled 'Putting the supplier cart before the distributor horse in travel' I discussed how creating open inbound APIs could help to foster connectivity between supply and distribution and encourage those who are not using online systems to adopt them in order to open up distribution opportunities. 

In addition to this discussion I also wanted to share my thoughts on who should and should not be holding the bag in terms of the costs of the API integration.


Over the years, I've been directly involved in the integration of dozens of APIs from providers in and out of the travel space.  I've worked with over 50 payment gateway APIs, integrated hotel, air, and package booking APIs, mapping, geoip, messaging, and currency APIs.  Twenty of those gateways and several of the other dedicated service APIs are now integrated into Rezgo for the purposes of processing payments or providing added functionality for our Rezgo customers. 

Needless to say, I've seen some really good, well documented APIs, and I've seen some of the most ridiculous excuses for APIs.  What all of them have in common, however, is a philosophy of connectedness.  You can't after all claim to be open to connect if you don't actually have a method for connecting.

For the most part, though, payment gateway, currency conversion, and geoip APIs all do fairly straightforward processes.  They are relatively simple in design and provide a very simple (specific) response.  In the case of travel, the APIs tend to become quite complex.  Selling travel is a complex process, so it's not hard to fathom that the APIs associated with selling travel are also complex.  As a result, they also tend to be top heavy.  By this I mean that only the upper echelons of the travel industry have APIs.  The large OTAs, GDSes, CRS, and PMS providers tend to have APIs but the small providers tend not to have them (or even know what they are).  The outcome is that there are APIs for distribution but no APIs for accessing supply.

But do the small suppliers require APIs for the purposes of selling direct to customers?  Although most would argue no, I would argue that YES, a good API is required for the purposes of selling direct.  Why? Because a solid API allows for rapid development of third party tools that can aid in the direct selling process.  In the case of Rezgo, for example, all our front-end interfaces including the white label, vendor/affiliate booking engine, WordPress plugin, opensource PHP booking engine, and the new mobile interface are built on top of our XML API.  Our API processes over a million XML requests and responses a day.  The majority (95%) are for direct to supplier sales.  We also have a number of Rezgo suppliers who have customized their interfaces on top of the XML API or integrated legacy reservation systems with their Rezgo system to manage real-time availability.

When it comes to connecting to a distribution channel, however, who should absorb that cost?  A supplier who has already spent the money to develop an API is going to argue that the distribution channel needs to connect with their API.  If the supplier brand is big enough, then I can see the argument, but you have to look at it from the perspective of the cost benefit for the two channels.

A large brand, for example a famous attraction, is already going to have a ticketing platform and direct sales channel via the web.  For customers who purchase vouchers outside of the attraction's own website, the process of redeeming the voucher requires them to wait in line (potentially) and actually collect the ticket on site before entering the venue.  The preferred method is to direct connect to the supplier's ticketing platform (assuming they have an API) so that tickets are generated when the booking is made so the customer can enter the park or venue without waiting.  The problem with this however, is that it only benefits the customer (reduces their time in lines) and the venue (integrates directly with their system).  There is no direct benefit to the distribution channel because this is a post sales integration.

In the case of smaller suppliers who are all using the same reservation platform such as Rezgo, the benefit to connect clearly lies with the supplier because the distribution channel is a potentially good source for incremental revenue.  Will the supplier pay for the integration? Probably not, but in aggregate the reservation platform may be able to do the integration and spread the costs of the integration out across their user base without make it an onerous expense for anyone.  In the case of Rezgo, an increase in incremental revenue would generate transaction fees that can help to cover the cost of integration.  The same may not be true for other reservation systems that simply charge a monthly fee.  In fact, in many cases, increasing incremental bookings and revenues for the end supplier are not a priority since they don't provide any additional revenue for the reservation software provider.

Regardless of whether the supplier, supplier's reservation system, or the distribution partner foots the bill for the integration, the overall integration costs will be lessened if the distribution partner has an inbound API.  Integrations with well documented APIs introduce fewer bugs into the core system and generally allow the integration to be managed outside of the core application.  When deciding who is going to pay for an integration, take the time to work with the partner to determine who has the resources and the expertise to get it done.  Sometimes it is simply better to leave the work to the one who can get it done in the most time and cost efficient manner, regardless of who has the most to gain from the integration.

About
My name is Stephen Joyce and I am the CEO of Rezgo, a software as a service online reservation system for tour and activity operators.  I've been working in travel technology, specifically web based travel, since 1995.  Since that time I've worked on creative, project management, development, quality assurance, system analysis, and architecture.  Now I get to work with a team of amazing people who help make Rezgo the system it is today.

Besides my work with Rezgo, I'm also passionate about developing standards and APIs.  I am the Chair of the Board of Directors of the OpenTravel Alliance, a non-profit organization whose mandate is to develop and foster messaging standards for travel e-distribution.  I travel a fair amount, usually in the Fall, Winter, and Spring to conferences

www.tourismtechnology.rezgo.com