To close our travel blogging series with some advice, today we will hear from Xoomworks Technology’sGlobal Solutions Director, Joe Thompson, who will detail four and a half things one needs to know about juggling hotel supplier APIs.
“If you’re running a successful travel booking system you’ve probably spent a fair bit of time figuring out exactly what your booking path needs to look like. You’ve skillfully matched your workflow to the needs of your underlying supplier so everything works beautifully and your users can search, shop and book without friction as they glide through the checkout.
And then BAM! Trying to integrate your second, third and fourth supplier into the system breaks everything. Suddenly a search for hotels in Bogota returns properties in New Jersey, half your payment options aren’t accepted at half your listed hotels, and amenities are now described in Amharic.
Building a Travel Site?
Here’s Four and a Half Things You Need To Know About Juggling Hotel Supplier APIs
Allow us to take apart this nightmare and look at some of the realities of using multiple hotel suppliers in your system:
Don’t know much geography? Turning place names into lat/long coordinates is a job all by itself. When you use a single supplier they will often provide some kind of service to do this for you but when you are shopping multiple suppliers simultaneously you will need to know in advance which list of hotels you’re asking for, and that means building a system which understands which hotels sit inside which geographic area.
Cache is king There are plenty of hotel APIs which don’t require you to store any information yourself. All the listings, content, policies and descriptions can be pulled from the supplier API as required together with live pricing and availability to match your search. Problem is, different suppliers, behave in different ways. If you want to give your users a consistent experience regardless of which supplier the product is coming from, odds are you will need to store something locally to make it all work.
Normal is worse than degrading Some suppliers provide rich descriptive content about their properties together with hi-res images and full itemised lists of the amenities and benefits they offer. Others provide very little apart from a rate. If you try to normalise content across all suppliers you will quickly end up with a template based on the lowest common denominator – and that’s bad for everyone. Instead, design pages assuming a best case scenario and then make certain the experience degrades gracefully, ensuring that every property shows its best side no matter what level of information is provided.
Not all APIs are created equal Pretty much every hotel supplier API has the same core functionality – returning lists of prices and availability at their properties. Once you scratch the surface, however, little differences start to emerge which can ruin the experience you’re offering your users. Perhaps you need to filter results down to only those hotels with an indoor pool? What if your site specialises in package deals with inclusive breakfast? What about if your users want to pay in a currency your supplier doesn’t offer? It’s almost certain you will need to find solutions to these kinds of challenges once you start integrating multiple hotel suppliers into your feed.
And-A-Half. Don’t forget the offline world, too That’s right. Behind your fully integrated real-time API integration there is a bunch of real-world processes for things like payment reconciliation and customer services. Things tend to get complex with the square of the number of systems involved, which is fine when you’ve got one supplier. Make sure everything you’ve figured out to work for your first supplier is also going to work for subsequent ones.”
Click our Infographic above for a larger version or to download it to your device.
To take a look back on our travel blogging series and read older blog posts, click here.