| Date | Description |
|---|---|
| 5 Jan 2022 | Corrected response schema details in /bookings/{booking-reference}/cancel and /bookings/{booking-reference}/cancel-quote to indicate that status and bookingId are required properties |
| 15 Nov 2021 | Added Basic-access Affiliate postman collection to Testing section |
| 5 Nov 2021 | Clarified description of exp-demo header parameter |
| 2 Nov 2021 | Added "LOCATION" as option for logistics.travelerPickup.locations[].pickupType in product content response |
| 28 Oct 2021 | Updated Booking Concepts – Booking questions – Conditional booking questions table |
| 15 Oct 2021 | Modified PriceObject schema in response from /availabililty/* endpoints to include provision for commission-payment-model merchants. See /availability/check for example |
| 13 Oct 2021 | Added section: How to determine if a product option supports pickup |
| 7 Oct 2021 | Added "TRANSFER_ARRIVAL_DROP_OFF" booking question details in Booking details – conditional booking concepts section |
| 1 Oct 2021 | Changed 'standard access' to 'full access' in Access to endpoints section |
| 1 Oct 2021 | Added note about "TRANSFER_PORT_CRUISE_SHIP" booking question to Booking concepts – Booking questions section |
| 27 Sep 2021 | Added note about time-out recommendation to /bookings/book |
| 16 Sep 2021 | Removed topX and modified options for sortOrder request parameters in /attraction/reviews/ endpoint |
| 13 Sep 2021 | Added reference element to Supplier schema of ActiveProduct |
| 6 Sep 2021 | Modified available options for sortOrder request parameter in /v1/taxonomy/attractions and /v1/search/attractions endpoints |
Previous updates: See Update log
If you require help or technical advice while you are carrying out your integration, please contact the onboarding team via email at: affiliateapi@tripadvisor.com
If you have completed your integration and your site is operational, please see our Support procedures page for what to do if you encounter a problem and require support.
The Viator Partner API v2 comprises a set of endpoints that can support the operation of a fully-featured tours and experiences booking website or application; or, it can be integrated with your existing travel-booking software.
The API exposes a variety of services that allow the retrieval of all product details, such as descriptive text and structured metadata, pricing, terms and conditions, photos and reviews. This data can either be ingested and managed on your local system, or calls can be made in real time to retrieve content in response to your users' activity on your systems.
The API allows product content, pricing and availability data to be retrieved in bulk or queried in real-time, it can perform pricing calculations according to the number and type of traveler and product option combinations available, and it supports availability and pricing holds as part of its booking and booking-cancellation functionality.
The Viator Partner-API is a designed for use by organizations partnered with Viator as Affiliate partners or Merchant partners.
Affiliate partners have full access to the areas of the API relating to content, but sales of Viator products must be carried out on the Viator site itself.
When a customer wishes to book a product from an affiliate's site, they are instead redirected to the relevant product page on viator.com via a unique URL in order to complete the purchase. Once on the Viator site, a cookie is set such that all transactions will accrue a commission for that partner until the cookie expires.
Purchases of products originating from the affiliate's site are recorded and a commission on these sales is paid periodically.
For more information on this partner type, see: Viator's Affiliate API Solution
The merchant partner relationship is one in which the partner is the merchant of record; i.e., the partner takes full responsibility for all financial records and transactions carried out by their users, as well as providing customer support with regard to providing general assistance, processing cancellations and refunds, and liaising between suppliers and customers when the need to communicate arises.
For more information on this partner type, see: Viator's Merchant API Solution
The Viator Partner-API v2.0 is a fully-redesigned system with regard to our previous API products. It includes all key fuctionality available in previous versions, but now provides nearly fully-structured data elements, and a more modern, concise and easily-understandable interface.
In addition, we have made significant improvements to performance across all functions of the API, and particularly in the area of product content and availability data ingestion.
Data ingestion has been greatly improved over previous versions of this API. Now, partners need only perform a single initial ingestion of data; then, only new and updated product content, availability and pricing information is retrieved as a 'delta update' as it becomes available.
In addition:
Improvements to availability schedule ingestion performance and usability have been achieved:
Availability is now communicated by providing an overall schedule season and specifying unavailable dates instead of available dates, a significantly more compact format that improves transfer speeds and minimizes storage needs
Availability and pricing information is given on a days-of-the-week basis, which can help with filtering and improving visibility of product availability for customers.
Information about special pricing periods that may be running throughout a product's seasons is included and is easy to interpret, allowing partners to surface promotions to customers.
Accurate pricing and applicability information for products that have 'per unit' (group) pricing is now included in the availability & pricing response; whereas support for this pricing model was limited in previous versions of this API. This allows partners to improve pricing exposure for these products.
Providing structured content is a major focus of this API. Product information that was previously stored as natural-language descriptions in a single, lengthy field is now represented in intuitively-structured, machine-interpretable schemata that empowers partners to apply finely-grained merchandising control, including:
The real-time availability check endpoint:
The booking workflow now includes an optional booking-hold step, which allows you greater predictability of a successful booking, thereby increasing conversion rates by decreasing friction in the booking flow.
The booking hold endpoint supports two kinds of hold:
The real-time availability and pricing endpoint also delivers ~5% faster performance than previous versions of this API.
The API endpoints accessible to you depend on which kind of partner you are; affiliate or merchant.
Basic-access Affiliate partners have access to a limited subset of the non-transactional endpoints of the Viator Partner API. The basic-access tier allows affiliates to quickly get started building their site with fewer complexities.
Full-access Affiliate partners have access to all non-transactional endpoints; i.e., everything except booking, booking hold and booking cancellation endpoints. In addition, full-access affiliates have access to additional legacy endpoints that provide functionality that helps to support attractions.
Merchant partners have access to all endpoints apart from the attraction endpoints designed for use by affiliate partners.
The following table describes which partner types have access to which endpoints:
| Endpoint | Basic-access Affiliate | Full-access Affiliate | Merchant |
|---|---|---|---|
| /products/search | ✅ | ✅ | ✅ |
| /products/modified-since | ❌ | ✅ | ✅ |
| /v1/taxonomy/destinations | ✅ | ✅ | ✅ |
| /locations/bulk | ✅ | ✅ | ✅ |
| /products/tags | ✅ | ✅ | ✅ |
| /products/booking-questions | ❌ | ❌ | ✅ |
| /v1/taxonomy/attractions | ✅ | ✅ | ✅ |
| /v1/search/attractions | ❌ | ✅ | ❌ |
| /exchange-rates | ✅ | ✅ | ✅ |
| /v1/support/customercare | ❌ | ✅ | ❌ |
| /products/{product-code} | ✅ | ✅ | ✅ |
| /products/bulk | ❌ | ✅ | ✅ |
| /reviews/product | ❌ | ✅ | ✅ |
| /v1/product/photos | ❌ | ✅ | ✅ |
| /v1/attraction | ❌ | ✅ | ❌ |
| /v1/attraction/reviews | ❌ | ✅ | ❌ |
| /v1/attraction/photos | ❌ | ✅ | ❌ |
| /v1/attraction/products | ✅ | ✅ | ❌ |
| /availability/check | ❌ | ✅ | ✅ |
| /availability/schedules/{product-code} | ✅ | ✅ | ✅ |
| /availability/schedules/modified-since | ❌ | ✅ | ✅ |
| /availability/schedules/bulk | ❌ | ✅ | ✅ |
| /bookings/hold | ❌ | ❌ | ✅ |
| /bookings/book | ❌ | ❌ | ✅ |
| /bookings/status | ❌ | ❌ | ✅ |
| /bookings/cancel-reasons | ❌ | ❌ | ✅ |
| /bookings/{booking-reference}/cancel-quote | ❌ | ❌ | ✅ |
| /bookings/{booking-reference}/cancel | ❌ | ❌ | ✅ |
Access to the API is managed using an API key that is included as a header parameter to every call made to all API endpoints described in this document.
| Header parameter name | Example value |
|---|---|
| exp-api-key | bcac8986-4c33-4fa0-ad3f-75409487026c |
If you do not know the API key for your organization, please contact your business development account manager for these details.
Please note that language localization is now controlled on a per-call basis. Previously, localization settings were configured per API-key; whereas, under the present scheme, organizations have a single API key.
Language localization is accomplished by specifying the desired language as a header parameter (Accept-Language). See Accept-Language header for available langage codes.
The Accept-Language header parameter controls the language into which the natural language fields in the response from each endpoint will be translated.
Note: You can only specify languages that have been configured for your API-key. Therefore, if you wish to access additional languages, you will need to contact your business development account manager.
| Language | Accept-Language parameter value |
|---|---|
| English | en, en-US |
| Danish | da, da-DK |
| Dutch | nl, nl-NL |
| Norwegian | no, no-NO |
| Spanish | es, es-ES |
| Swedish | sv, sv-SE |
| French | fr, fr-FR |
| Italian | it, it-IT |
| German | de, de-DE |
| Portuguese | pt, pt-PT |
| Japanese | ja, ja-JP |
| Chinese (traditional) | zh-TW |
| Chinese (simplified) | zh-CN |
| Korean | ko, ko-KR |
In order to ensure the predictability of the behavior of this software, we have implemented a versioning strategy to handle updates to the API contract, as well as a mechanism to specify which version of the API you wish to access.
When we release a new version of this API, partners have the option of continuing to use the existing version or migrating to the updated version when they are ready.
The approach to versioning for this API is as follows:
The following types of change are considered backward-compatible, and will not result in a version release when introduced. Therefore, partners must ensure their implementation can handle such changes gracefully.
These changes comprise:
The following types of change are considered breaking changes and will result in the release of an incremented version of this software:
It is mandatory to specify which version of the API you wish to use via the 'Accept' header parameter in the request to each API endpoint; e.g., Accept: application/json;version=2.0. Omitting the version parameter will result in a 400 Bad Request response.
Example valid request:
curl --location --request GET 'https://api.sandbox.viator.com/partner/products/modified-since?cursor=MTU5MjM1NTM0MXwxMTM5ODZQNA==' \
--header 'exp-api-key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx' \
--header 'Accept-Language: en-US' \
--header 'Accept: application/json;version=2.0'Example error response:
{
"code":"INVALID_HEADER_VALUE",
"message":"Accept header is missing or has invalid version information",
"timestamp":"2020-09-02T03:43:23.303946Z",
"trackingId":"3D45567E:2D25_0A5D03AB:01BB_5F4F14A5_394639:3DB7"
}This API supports gzip compression. Therefore, if you include gzip in the Accept-Encoding header parameter in the request, the API will respond with a gzip-compressed response.
You can retrieve the core product-content details from the following endpoints:
You can retrieve the availability schedules for products using the following endpoints:
There are nine endpoints necessary for the seamless operation of this API that have not yet been updated to the 'v2-style' functionality of the other endpoints.
V1 endpoints available to both partner types:
destinationIdattractionIdV1 endpoints for affiliate partners only:
These nine v1 endpoints operate differently to the v2 endpoints.
In particular:
data elementsuccess element being true or false, not the HTTP status code, which will be 200 in every case in which a response was able to be returned, regardless of any error(s)Example V1 error response:
{
"errorReference": "C0AA8A15:ED5E_0A2806D6:01BB_5F755F7F_54AA9:03D6",
"data": null,
"dateStamp": "2020-09-30T21:47:59+0000",
"errorType": "EXCEPTION",
"errorCodes": [
"UNKNOWN_ERROR"
],
"errorMessage": [
null
],
"errorName": "NullPointerException",
"extraInfo": {},
"extraObject": null,
"success": false,
"totalCount": 1,
"errorMessageText": [],
"vmid": "331009"
}This following diagram shows the different data element names in the responses from the v1 and v2 product content endpoints from which the sections of the product display page for product 114491P5 on Viator.com are sourced.
treatAsAdult flagIn v1 of this API, the requirement (or lack thereof) for an adult to be included in a booking was communicated via the treatAsAdult flag in the items of the ageBands[] array in the response from the /product endpoint. The default assumption in the v1 API was that at least one adult is required per booking unless the treatAsAdult flag is set to true for a non-adult age-band, in which case the inclusion of one traveler from that age-band is sufficient to fulfil the requirement.
See: Key concepts – Working with age-bands (Partner API v1) for more information.
In v2 of this API, whether an adult traveler is required in order to make a booking is communicated via the bookingRequirements.requiresAdultForBooking flag in the response from any of the product content endpoints.
If this flag is true, at least one traveler from one of the 'ADULT', 'SENIOR' or 'TRAVELER' age-bands must be included when making the booking.
In version 2 of the Viator API, the concept of 'product categories' that was utilized in version 1 has been replaced by tags.
In version 1, the list of categories and subcategories was available on a per-destination basis using v1's /taxonomy/cateogories endpoint. This list could be used to construct a category tree for display to the user; or, to aid in search.
In version 2, tags can be used to replicate this functionality simply by mapping the original v1 subcategory to its v2 tag equivalent. Tag information is available from the /products/tags endpoint.
These mappings are detailed in this Excel spreadsheet: v1 category and subcategory mappings to v2 tags.
All v2 tags that correspond to categories or subcategories in v1 are listed in the spreadsheet, which can be interpreted as per this example:
| v2 tag display name | v2 tagId | v1 subcategoryId | v1 subcategoryName | v1 categoryId | v1 groupName |
|---|---|---|---|---|---|
| Hot Air Balloon Rides | 12027 | 3 | Balloon Rides | 1 | Air, Helicopter & Balloon Tours |
The example above shows that the v2 tag "Hot Air Balloon Rides", which has a tagId of 12027, corresponds to v1's "Balloon Rides" (subcategory 3), which falls under "Air, Helicopter & Balloon Tours" (category 1).
In the response from the v2 endpoint /products/tags, "Hot Air Balloon Rides" (tagId: 12027) is shown here:
{
"tagId": 12027,
"parentTagIds": [
21715,
21913,
21436,
21909
],
"allNamesByLocale": {
"de": "Heißluftballonfahrten",
"no": "Turer i varmluftballong",
"sv": "Flygturer i varmluftsballong",
"pt": "Passeios de balão",
"ko": "열기구 타기",
"en_AU": "Hot Air Balloon Rides",
"en": "Hot Air Balloon Rides",
"it": "Giri in mongolfiera",
"fr": "Vols en montgolfière",
"en_UK": "Hot Air Balloon Rides",
"es": "Paseos en globo aerostático",
"zh": "热气球之旅",
"zh_HK": "熱氣球之旅",
"zh_TW": "熱氣球之旅",
"ja": "熱気球での飛行体験",
"zh_CN": "热气球之旅",
"da": "Varmluftballonture",
"nl": "Ballonvaarten"
}
} This corresponds to the following result (Balloon-rides; category 1, subcategory 3) in the response from the v1 endpoint /taxonomy/categories:
{
"sortOrder": 1,
"thumbnailURL": "https://hare-media-cdn.tripadvisor.com/media/attractions-splice-spp-154x109/06/75/b7/96.jpg",
"subcategories": [
{
"sortOrder": 1,
"subcategoryUrlName": "Balloon-Rides",
"subcategoryId": 3,
"subcategoryName": "Balloon Rides",
"categoryId": 1
},
{
"sortOrder": 2,
"subcategoryUrlName": "Air-Tours",
"subcategoryId": 1,
"subcategoryName": "Air Tours",
"categoryId": 1
},
{
"sortOrder": 3,
"subcategoryUrlName": "Helicopter-Tours",
"subcategoryId": 2,
"subcategoryName": "Helicopter Tours",
"categoryId": 1
}
],
"thumbnailHiResURL": "https://hare-media-cdn.tripadvisor.com/media/attractions-splice-spp-674x446/06/75/b7/96.jpg",
"productCount": 76,
"groupName": "Air, Helicopter & Balloon Tours",
"groupUrlName": "Air-Helicopter-and-Balloon-Tours",
"id": 1
},
Using the spreadsheet, as above, you can replicate the category tree and categorise products accordingly using a product's tags, which are provided in the product content response.
Any particular product may consist of a number of variants, each of which is referred to as a 'product option'. In previous versions of this API, and in the tours and activities sector in general, product options are also referred to as 'tour grades'.
For example, product options might represent different departure times, tour routes, or packaged extras like additional meals, transport and so forth.
The product options available for a product can be found in the productOptions array in the responses from any of the product content endpoints.
An example productOptions array for the product 5010SYDNEY is as follows:
"productOptions": [
{
"productOptionCode": "48HOUR",
"description": "Duration: 2 days: FREE BONUS ENTRY to Sydney Tower with every Deluxe ticket end 31st March<br/>48 Hour Premium Ticket: Unlimited use on Big Bus Sydney & Bondi Tour for 48 hours from time of first use PLUS a guided walking tour of The Rocks, Syd",
"title": "48 Hour Premium Ticket ",
"languageGuides": [...]
}