• Home

Using v8 API

Overview

The newest version of the Tripadvisor API (v8) is designed to help Partners increase conversions by providing richer availability data to Tripadvisor. The document below highlights key changes and walks you through how you can use the new API. Tripadvisor's v8 API is described as a Swagger/OpenAPI specification file. Swagger comes with tools to autogenerate the model of the API into multiple different languages to make integrations with our API easier. In order to support your API implementation please use and download our v8 API Spec on Swagger. 

Major enhancements:

Taxes and fees broken out separately

The new API supports a more detailed breakdown of taxes and fees. This is important because it will allow Tripadvisor to display taxes, fees and base rates in ways that are more relevant to each market. Upgrading to the new API will help you stay competitive and attract bookings from travelers looking for the lowest price. Specifically, we have added new subtypes in “line_items”, found under ‘hotels.available.room_rates’.

Single Tripadvisor endpoint that merges /hotel_availability and /booking_availability calls

We have merged Hotel Availability and Booking Availability (used in Instant Booking only) by adding request parameters to specify the depth of data and caching strategy that you need to return in your response. This change will allow you to pass different content pieces based on the requested parameters. For example, we know that certain room and rate features – refund and cancellation policies, bed configuration, breakfast options and more –  can influence booking decisions. By Tripadvisor requesting this subset of content in addition to the cheapest priced room, hotel shoppers will be able to see these features in the PriceFinder module on Tripadvisor, making them visible earlier and motivating potential guests to book with you. Detailed use-cases covered below. This single API endpoint allows the flexibly to change the information Tripadvisor requests in the future without requiring us to version the API (make breaking changes), and therefore without requiring any effort on the part of Partners. Detailed use-cases covered in section "How to leverage new API" below.

Refactoring RoomType, RatePlan, and RoomRate identifiers and rate features

We have introduced the following changes to the API:

• Changed RoomRates from using a list to using a map

• Added optional Persistent Room Type Code, Persistent Rate Plan Code, and Persistent Room Rate Code fields to identify information that persists between requests. We strongly recommend Partners use a persistent identifier that does not change with each availability request

• RoomType map, RatePlan map, and RoomRate map keys only need to persist per request

Updated API fields for better alignment

In order to make maintaining, updating, and implementing our API easier for both Partners and Tripadvisor, we have:

• Removed unused fields and functionality (such as "final_price" and "discount_type", or "adjustment" line items).

• Elaborated 'cancellation_rules' to allow for start and end time for a cancellation policy

• Refactored how/where errors are communicated. 

  • Response level - Provided mechanism for Partners to elaborate type of HTTP error (e.g. http 200 error)

  • Location level - In Hotel Availability, added ability to provide errors per-location (e.g. in a multi-hotel availability request. You can now specify which hotels have an error in their response) 

 

For more useful information please visit our V8 FAQ.