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.
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)
Tripadvisor can display your rate as 'Free Cancellation' and 'Pay At Stay' in Hotel Availability search. More information on this feature is covered here.
For more useful information please visit our V8 FAQ.