Viator Merchant API v1

The legacy v1 merchant-partner specification still published by Viator, exposing taxonomy, product, photo, review, availability, pricing-matrix, booking, voucher and cancellation services under viatorapi.viator.com/service. Superseded by the Partner API v2 but retained in the public documentation.

OpenAPI Specification

viator-merchant-api-v1-openapi.json Raw ↑
{
  "openapi": "3.0.1",
  "info": {
    "title": "Viator API Documentation & Specification \u2013 Merchant Partners",
    "description": "<style type='text/css'>\ncode { white-space: nowrap; }\na { font-weight: bold; }\n\nfigure {\n  width: 100%;\n  text-align: center;\n  font-style: italic;\n  font-size: smaller;\n  text-indent: 0;\n  border: thin silver solid;\n  margin: 0.5em;\n  padding: 0.5em;\n}\n\n</style>\n\n## Updates\n\n### Latest update: \n\n| Date | Description |\n|------|-------------|\n| 23 Feb 2023 | Modified 'Building in the sandbox environment' section of the [Selling on-request products](#section/Key-concepts/Selling-on-request-products) section |\n| 16 Nov 2022 | Mentioned need to verify whether a particular tour grade offers pickup prior to booking | \n| 15 July 2022 | Modified description of [/booking/availability](#operation/bookingAvailability) endpoint and added advice to country-code and full-detail phone number field descriptions to communicate that a plus (`+`) symbol **must** be included at the beginning of the string |\n| 26 May 2022 | Added advice about review authenticity: [Key concepts - Review authenticity](#section/Key-concepts/Review-authenticity) |\n| 5 Jan 2022 | Corrected `travelDate` format in example request in [/booking/calculateprice](#operation/bookingCalculateprice)| \n| 30 Sep 2021 | Corrected `data.ageBands` specification in [/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades) |\n| 27 Sep 2021 | Added note about time-out recommendation to [/booking/book](#operation/bookingBook) |\n| 6 Sep 2021 | Modified available options for `sortOrder` request parameter in [/taxonomy/attractions](#operation/taxonomyAttractions) endpoint |\n| 3 Feb 2021 | Added [Special offers and on-sale pricing](#section/Key-concepts/Special-offers-and-on-sale-pricing) section |\n| 28 Oct 2020 | Updated FAQ section re booking questions, traveler names, and pricing |\n| 16 Sep 2020 | Modified FAQ section re booking currencies, supplier name display and requesting additional reviews |\n| 20 July 2020 | Added [Booking references](#section/Key-concepts/Booking-references) section |\n\n**Previous updates**: See [Update log](#section/Appendices/Update-log)\n\n# Overview\n\nThe Viator Partner API 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.\n\nThe API exposes a variety of services that allow the retrieval of all product details, such as descriptions, pricing, terms and conditions, photos and reviews. This data can either be ingested periodically 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.\n\nThe API allows product availability schedules to be retrieved in bulk or queried in real-time, and it can perform pricing calculations according to the number and type of traveler for the wide variety of product option combinations typically available in the tours and activities sales workflow.\n\nThe API provides booking and post-booking functionality, allowing booking requests, ticket purchase, and booking status updates.\n\nVarious utility services are available to map between yours and Viator's data taxonomy.\n\n**Please note:** The API does not provide services for storing data, such as user accounts. We assume that merchant partners have their own systems for storing this data.\n\n## Who is the API for?\n\nThe Viator Partner API is designed for use by organizations and individuals partnered with Viator in one of the following capacities:\n\n### Merchant partners\n\nA merchant partner is one who operates as the merchant of record; i.e., takes full responsibility for all monetary transactions carried out by their users, as well as providing customer support with regard to providing help, processing cancellations and refunds, and liaising between suppliers and customers when the need to communicate information arises.\n\nMerchant partners are invoiced periodically by Viator for all product sales. You will need to demonstrate that you have access to the appropriate infrastructure to effectively support the requisite business operations in order to become a merchant partner.\n\n### Viator Branded Affiliates (VBAs)\n\nVBAs 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; therefore, access to the booking or transactional endpoints necessary to operate as the merchant of record (i.e., merchant partners) is restricted. \n\nWhen a customer wishes to book a product from a VBA partner's site, they are instead redirected to [viator.com](https://viator.com) in order to complete the purchase; whereas, merchant partners are able to process and manage bookings through the Viator API itself, allowing their customers to book products without leaving the partner's site.\n\nViator affiliates instead generate unique URLs that redirect their users to the Viator site, resulting in a cookie being set such that all transactions will accrue a commission for that partner until the cookie expires.\n\nPurchases of products originating from the VBAs site are recorded and a commission on these sales is paid periodically.\n\n- **Note**: VBA partners should refer to a different document for technical specifications relevant to their partner type. If you are a VBA partner, please navigate to: [https://docs.viator.com/partner-api/affiliate/technical/](https://docs.viator.com/partner-api/affiliate/technical)\n\n### VBAs with booking capability\n\nVBAs also have the option of allowing their customers to process bookings directly from their site and via the API \u2013 similar to a merchant partner \u2013 without being redirected to viator.com to complete their transaction. This partner type sends customer details, product details and credit card payment information via the API, but Viator retains control of and responsibility for processing payments and customer support.\n\n### White label partners\n\nWhite label partners do not operate their own site infrastructure. Instead, Viator provides a white label site with full functionality that can be branded according to the partner\u2019s wishes.\n\n## Uses of the Viator Partner API\n\nThe Viator Partner API is used to carry out the following tasks:\n\n### Product search and ingestion\n\nPartners can use the product search endpoints to retrieve lists of products from Viator\u2019s inventory relevant to their business. The available search criteria include:\n\n- The location (destination) in which the product operates\n- Whether the product is associated with a well-known tourist attraction; e.g., Empire State Building\n- The type of product (known as its category and/or subcategory)\n- The time period during which the product operates \n- Words or phrases that occur in a product's description via a free-text search\n\nPartners who prefer to download product details periodically (instead of performing all operations in real time in response to user behavior) do so by using the product search endpoints to compile a list of products that they wish to sell on their site. They then download comprehensive product details for each via the /product endpoint.\n\n#### Product search endpoints:\n\n| Endpoint | Use |\n|-|-|\n| [/search/products](#operation/searchProducts) | Allows searching for products according to: destination / location, relationship to a known tourist attraction; category and/or subcategory; date of operation |\n| [/search/products/codes](#operation/searchProductsCodes) | Retrieves product details for products that match a list of product codes (unique identifiers for the product) |\n| [/search/freetext](#operation/searchFreetext) | Retrieves product details for products that include the search terms in the product's description and details. |\n| [/available/products](#operation/availableProducts) | Retrieves products that are identified by specific product codes, operate during a specified day range and accept a certain number of adult travelers |\n\n#### Product information endpoints:\n\nAll information about a product that must be communicated to customers prior to purchase is available via [/product](#operation/product) and its auxiliary endpoints. This content is generally used to construct product display pages and for performing local searches.\n\nImportant information about a product includes:\n\n- Product and supplier names\n- Geographic location\n- Product description\n- Category and subcategory\n- Photos (from both users and the supplier)\n- User reviews and ratings\n- Product options (variants of the tour/activity, such as starting times, passenger mix options, and inclusions/add-ons, including basic pricing information for each)\n- Which age ranges can participate\n- Booking details\n- Cancellation policies\n- Basic pricing\n- Logistics\n  + Inclusions (e.g., provided meals)\n  + Exclusions (e.g., entrance fees to visited attractions)\n  + Health restrictions and accessibility\n  + Departure times\n  + Passenger pick-up\n  + Duration\n  + Tour routes\n\n### Availability\n\nThe availability of a tour is communicated via the API's availability endpoints. The availability aspects of a product include:\n\n- On which days and at which times the product is available to be booked\n- Whether the product option (variant) supports a certain combination of passengers according to age and number\n- Pricing information\n\nSome partners choose to bulk-ingest availability information for their products in order to expedite this part of the customer workflow or to facilitate a local search functionality on their website; but, because this information changes very regularly, a final real-time call is generally recommended to ensure that when the booking request is submitted by the customer it is unlikely to fail on account of a change in availability.\n\n#### Availability endpoints\n\n| Endpoint | Use |\n|-|-|\n| [/booking/availability](#operation/bookingAvailability) | Returns the product option with the lowest price that is available on each day |\n| [/booking/availability/dates](#operation/bookingAvailabilityDates) | Returns all available dates for a product (but without regard to product option) |\n| [/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades) | Returns all product options for a product that are available on the specified day for the specified passenger mix |\n| [/booking/availability/tourgrades/pricingmatrix](#operation/bookingAvailabilityTourgradesPricingmatrix) | Returns a detailed matrix of product options, passenger mixes and the pricing applicable to each combination |\n| [/booking/calculateprice](#operation/bookingCalculateprice) | Provides a reconfirmation of a product's availability with respect to the product option and passenger mix provided and calculates a final price; used as a final availability check immediately prior to making a booking |\n\n### Booking and cancellations\n\nMerchant partners and VBAs with booking capabilities can use the Viator Partner API to purchase the product through the [/booking/book](#operation/bookingBook) endpoint.\n\nThe API also provides services to:\n\n- Enquire about the status of an existing booking\n- Retrieve tickets/vouchers for the product\n- Cancel a booking\n\n#### Booking endpoints\n\n| Endpoint | Use |\n|-|-|\n| [/booking/book](#operation/bookingBook) | Make a booking / purchase a product |\n| [/booking/status](#operation/bookingStatus) | Retrieve multiple detailed booking statuses based on a range of specified criteria |\n| [/booking/status/items](#operation/bookingStatusItems) | Similar to [/booking/status](#operation/bookingStatus), but provides slightly less detail and can be called more frequently |\n\n#### Cancellation endpoints\n\n| Endpoint | Use |\n|-|-|\n| [/bookings/{booking-reference}/cancel-quote](#operation/bookingQuote) | Returns the expected outcome of a booking cancellation request (taking into consideration the product's cancellation policy) were the cancellation request performed immediately |\n| [/bookings/{booking-reference}/cancel](#operation/cancelBooking) | Cancels the booking and assigns a refund depending on the product\u2019s cancellation policy |\n\n### Auxiliary services\n\nTaxonomical data sets are required to interact meaningfully with the Viator Partner API; for example, mappings from destination (location of operation) to their respective identification codes. This information may occasionally change or be added to. Consequently, the API includes endpoints that return the most up-to-date versions of this information.\n\n#### Taxonomy endpoints\n\n| Endpoint | Use |\n|-|-|\n| [/taxonomy/destinations](#operation/taxonomyDestinations) | Retrieves a list of destination names, types and unique identifiers to be used when interacting with the Viator Partner API |\n| [/taxonomy/categories](#operation/taxonomyCategories) | Retrieves a list of product categories for a destination that can be used as a means of filtering when searching for products using the [/search/products](#operation/searchProducts) endpoint |\n| [/taxonomy/attractions](#operation/taxonomyAttractions) | Retrieves a list of tourist attractions (e.g., the Eiffel Tower or Empire State Building) and their associated identification codes to be used as a means of searching for available products; for example, in the [/search/products](#operation/searchProducts) service |\n| [/booking/hotels](#operation/bookingHotels) | Retrieves a list of hotels, including names and geographic locations, to be used when making booking requests |\n\n---\n\n# Authentication\n\n**Note**:\n\n- The authentication mechanism for this API has been updated recently. Now, partners can also authenticate using a [new style of API key](#section/Authentication/exp-api-key) that is included in each call as a <u>header parameter</u>. Previously, authentication was accomplished by including an API key as a query parameter.\n\n- Partners who are currently authenticating via the [API key query parameter](#section/Authentication/Legacy-API-keys) can continue to authenticate in this way; however, access to the new booking cancellation endpoints ([/bookings/cancel-reasons](#operation/cancellationReasons), [/bookings/cancel-quote](#operation/cancelBookingQuote) and [/bookings/cancel](#operation/cancelBooking)) does require the new-style of API key. All other endpoints remain compatible with both authentication methods.\n\n- If you would like to switch to the [new style of key](#section/Authentication/exp-api-key), please speak to your business development account manager.\n\n## API key\n\nAccess 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.\n\n| Header parameter name | Example value |\n|-----------------------|---------------|\n| exp-api-key | bcac8986-4c33-4fa0-ad3f-75409487026c |\n\nIf you do not know the API key for your organization, please contact your business development account manager for these details.\n\nPlease note that language localization is now controlled on a per-call basis. Previously, language localization was controlled via API-key configuration, with one language available per API key. Under the present scheme, you can access any language enabled for your organization's point of sale via a **single API key**. \n\nLanguage selection is accomplished by specifying the desired language as a header parameter (`Accept-Language`). See [Accept-Language header](#section/Appendices/Accept-Language-header) for available language codes. If you would like access to additional languages, please contact your business development account manager.\n\n## Legacy API key\n\nPreviously, authenticating to this API was accomplished by passing an API-key **as a query parameter** appended to the URI for each call; e.g.:\n\n```html\nGET https://viatorapi.sandbox.viator.com/service/taxonomy/destinations?apiKey=xxxxxxxxxxxxxxxxxx\n```\n\nThis method of authentication remains available for backwards-compatibility with existing implementations. If you would like to upgrade to the new style of API key, please contact your business development account manager. \n\n# Key concepts\n\n## Content ingestion and caching strategy\n\nMuch of the information you will need to retrieve from the Viator API \u2013 such as the taxonomy, product lists and product details \u2013 do not change frequently.\n\nTherefore, we recommend implementing a caching strategy in order to eliminate unnecessary traffic to Viator\u2019s servers and improve the operation of your site. \n\nThis section discusses the different strategies for retrieving and caching Viator\u2019s product catalogue.\n\nYou will need to decide on how you will retrieve and manage content from Viator\u2019s product catalogue. The two main options are as follows:\n\n### 1. API response caching\n\n*Partners retrieve content as-needed and cache responses on a service-by-service basis*\n\nIf you do not need to store product details locally, we recommend performing caching of on a service-by-service basis; i.e., storing the entire response and applying a time-to-live (TTL) of less than 24 hours.\n\n#### Benefits of API response caching\n\n* All the benefits of caching with minimal overhead\n* Minimal risk of serving stale or invalid data cached on the partner's side\n* No need to download data about products that are not selling\n* A smaller volume of local data improves cache hit performance\n* Fewer requests made of Viator's systems\n* Avoids rate limitations\n* Closer adherence to best practices\n* Removes need to manage a complex data structure locally\n\n#### Service endpoints to cache\n\nCaching should only be applied to services that yield infrequently changing data; i.e.:\n\n* [/taxonomy/destinations](](#operation/taxonomyDestinations)\n* [/taxonomy/categories](#operation/taxonomyCategories)\n* [/taxonomy/attractions](#operation/taxonomyAttractions)\n* [/search/products](#operation/searchProducts)\n* [/search/products/codes](#operation/searchProductsCodes)\n* [/search/freetext](#operation/searchFreetext)\n* [/product](#operation/product)\n* [/product/reviews](#operation/productReviews)\n* [/product/photos](#operation/productPhotos)\n* [/available/products](#operation/availableProducts)\n\n**Note**: these services should be considered cacheable even though some are POST and none include a Cache-Control HTTP header in their response.\n\n### 2. Periodic content ingestion\n\n*Partners download either the full product catalogue or a subset of the catalogue at regular intervals based on destination, linked attraction, or product category filters.*\n\n#### Who should use periodic ingestion\nThis approach may be preferable for partners whose requirements include:\n* **System agnosticism/data centralization** \u2013 i.e., partners who are simultaneously selling products from vendors other than Viator, have existing product databases or are likely to want to maintain a central product catalogue with a unified taxonomy / data structure\n* **Enhanced search capability** \u2013 i.e., the ability to apply different categorization rules, filters, exclusions or search optimizations to the product catalogue; e.g., grouping or filtering products according to criteria other than those supported directly by the Viator API (destination, attraction-link or category)\n\n#### Frequency of content ingestion\nWe recommend that you perform an ingestion of the product catalogue once every 24 hours.\n\n#### How to retrieve product codes\n\nMake a call to one of the product search services:\n\n* [/search/products](#operation/searchProducts) \u2013 to search by `destId` (destination), `catId` (category), `subCatId` (subcategory) or `seoId` (attraction)\n* [/search/freetext](#operation/searchFreetext) \u2013 free-text search across all identifying fields \n\n#### How to retrieve all products in the catalogue\n\nTo retrieve all products from the Viator catalogue:\n\n* Retrieve all available destination identifiers (`destId`) from the [/taxonomy/destinations](#operation/taxonomyDestinations) service\n* Iterate through the complete list of `destId`s you retrieved in the previous step, and call [/search/products](#operation/searchProducts) for each `destId`\n\n**Note**: As some products operate in multiple destinations, the same product code may be returned for a range of different destinations. Therefore, make sure your list of product codes only contains one copy of each code.\n\nYou may then iterate through this list of product codes to retrieve any other product details necessary in order to properly populate your local database with the information you require.\n\n#### Retrieving a subsection of the product catalogue\n\nYou may wish to retrieve only some of the products available in the Viator catalogue; for example, if your organization is only interested in selling products that operate locally.\n\nYour top level search using [/search/products](#operation/searchProducts) is restricted to one of the three main categorization methods for products; i.e., destination, category/subcategory, or attraction-link; however, you may employ your own methods to filter the selection of products based on any attribute in the product data structure.\n\n#### Dealing with pagination using `totalCount` and `topX`\n\nDue to the large number of results that can be returned by the [/search/products](#operation/searchProducts) service, the request might exceed the 30-second time-out limitation on both sandbox and live servers. Therefore, you will need to make multiple requests to this service including pagination information in order to retrieve all products that match your search criteria.\n\nThis is accomplished by sequentially requesting successive segments of the results using the `topX` request parameter together with the `totalCount` response field; i.e.:\n\n* For your first request, specify a `topX` of `\"1-100\"`\n  - **Note**: this range is *inclusive*; i.e., `\"topX\": 1-100\"` will yield the first 100 records \n* The first response will indicate the total number of records available through the value of the `totalCount` field in the response object; e.g.: `\"totalCount\": 13843`\n* For each subsequent request, specify the next logical 'chunk' of data via the `topX` parameter of the request; e.g.:\n  - \"topX\": \"1-100\"\n  - \"topX\": \"101-200\"\n  - ...\n  - \"topX\": \"13801-13843\"\n\n#### Rate limiting\n\nDue to the heavy load that pre-caching can place on Viator's servers and the downstream servers we connect to, we apply a rate limit of **150 requests per 10 second time window**.\n\nRequest rates exceeding this limit will result in a **HTTP 429 (Too Many Requests)** status code being returned.\n\n**Note**: The rate is calculated over a rolling 10-second time window\n\n* In order to avoid running-up against rate limits:\n  - insert a delay of 2s if you receive a HTTP 429 status code\n  - do not run this as a multi-threaded process\n\n## Review authenticity\n\n### Viator performs checks on reviews\n\nYou can only submit a review or rating of an experience to Viator if you were the person who made the booking through Viator. Before publication, each review goes through an automated tracking system, which collects information for each of the following criteria: who, what, how, and when. \n\nIf the system detects something that contradicts our publication criteria, the review is not published. When the system detects a problem with a review, it may be automatically rejected, sent to the reviewer for validation, or manually reviewed by our team of content specialists who work 24/7 to maintain the quality of the reviews on our site. In some cases, we will also send Viator customers an email asking them to validate their review before it is published. <br /><br />All Viator customers need to do is to click on the link provided in the email. \n\nAfter publication, our team checks each review reported to it as not meeting our publication criteria. Tripadvisor reviews that appear on the Viator site are subject to the same checks and moderation processes as set out above. It is not necessary to have booked an experience through Viator (or Tripadvisor) to submit a review of an experience to the Tripadvisor site.\n\n\n## Booking concepts\n\n### Booking types - *on-request* and *freesale*\n\nBookings made with Viator can be either *freesale* (immediate confirmation) or *on-request*, which require us to confirm with our product supplier that the product has not sold out and is still available. This difference must be clearly communicated to the customer during the price check and on the *order summary* post-purchase page.\n\nFor *freesale* bookings, the voucher becomes available immediately, and the customer's credit card will be charged at the time of booking. For *on-request* bookings, confirmation will be sent to the customer within a timeframe supplied in the [/booking/calculateprice](#operation/bookingCalculateprice) and [/booking](#operation/bookingBook) service responses.\n\nThe customer's credit card will be charged once their *on-request* booking is confirmed.\n\n### bookingEngineId\n\n`bookingEngineId` is a field returned in the responses from several endpoints documented in this manual. It is a **booking type specifier** indicating whether, when the product in question is booked, the booking will be `CONFIRMED` immediately or if it will remain `PENDING` even after the booking has been made, indicating that it is an on-request product.\n\n`bookingEngineId` takes *one of* the following values:\n\n  - `\"FreesaleBE\"` \u2013 the product will be confirmed immediately and the supplier will be sent a notification.\n\n  - `\"UnconditionalBE\"` - the product will be confirmed immediately and the supplier will not be notified.\n\n  - `\"DeferredCRMBE\"` - the product is an on-request product and the booking will not be confirmed immediately. The booking will remain with a `PENDING` status after it is made, to be confirmed by the supplier within the time specified in the `hoursConfirmed` field available in the booking response and post-booking services.\n\n  - `\"FreesaleOnRequestBE\"` - The product is freesale up until a certain number of days before the travel date, after which it becomes on-request. It is then referred to as being within the *on-request period*. If a booking is made within the on-request period, the product can be considered to be an on-request product. Once the booking has been made, the `bookingEngineId` will change to either `\"FreesaleOnRequestBE:OnRequest\"` or `\"FreesaleOnRequestBE:Freesold\"` depending on the travel date and the on-request period.                      \n\n### Tour grades\n\nProducts can have one or more *tour grades*. Each tour grade might represent a departure time or different tour option, such as additional meals, transport and so forth. If the tour grade code is `\"DEFAULT\"`, *do not* display this to the customer, simply hide the product's tour grade information.\n\n### Language options\n\nMany tours deliver a commentary in multiple languages using multilingual tour guides or with written or prerecorded information. Where available, the customer can preselect their preferred language option.\n\n### Traveler mix (pax)\n\nSome tour grades have defined traveler mixes used to price family passes; or, they might have special mixes for limited passenger tours, such as small buggies or weddings.\n\nThese traveler mixes are provided by the [/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades) service. You may need to display these to your customers so that they are able to understand why they can or cannot select a particular tour grade if there is a traveler mix mismatch.\n\n### Pick-up location and hotel lists\n\nSome products have pick-up and return shuttle bus services. For these tours, you will need the customer to supply a pick-up hotel, or they must select *live locally* or *hotel not yet booked* options.\n\nViator maintains pick-up hotel lists for many popular destinations. These lists are available for customers to select their pick-up location for various tours. For destinations without hotel lists, customers can enter the name of their hotel. If a customer's hotel is not listed, they should be able to enter a hotel name; however, pick-up may not be possible for that hotel.\n\n### Lead traveler\n\nEach tour booking requires a lead traveler to be identified. To identify the lead traveler in your request, set the `leadTraveller` flag to `true` in the traveler class.\n\n### Booking questions\n\nSome products have a list of one or more [booking questions](#section/Appendices/Booking-questions) that need to be asked. Some are mandatory. The question, a description, etc are provided in the product details object. The answers need to be included with the booking request.\n\n### SSL/HTTPS\n\nCalls to the [/booking/book](#operation/bookingBook) service *must* use a secure channel (https) as they contain credit card information.\n\n### Promo codes\n\nViator can create promotional (promo) codes for discounts and other purposes. As it's unlikely for you to wish to support this feature, we recommend supplying `null` in the `promoCode` field and not including any customer-entered fields during the checkout process.\n\n### Partner data\n\nPartners can also supply additional information for their own internal purposes. These are attached to booking reports and other materials for use in allocating commissions to agents and so forth.\n\n## Availability services\n\nProduct availability information can be retrieved with the following services:\n\n- [/booking/availability](#operation/bookingAvailability): get the tourgrade with the lowest price available on a day\n- [/booking/availability/dates](#operation/bookingAvailabilityDates): get all available dates for a product excluding days it does not operate and blockouts\n- [/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades): list all available tour grades for a specific day\n- [/booking/availability/tourgrades/pricingmatrix](#operation/bookingAvailabilityTourgradesPricingmatrix): returns available days only (ie days which have at least one tour grade available), and the pricing matrix for that tour grade on that day\n\n### Example: multiple departures in a single day\n\nMultiple departures in a single day (each represented by a tour grade) and the language options (langServices).\n\nThis request is for 3 adults on a helicopter tour:\n- **Note:** No prices are returned if the tour grade is unavailable.\n\n**Request object** ([/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades)):\n\n```javascript\n{\n  \"productCode\": \"2280AAHT\",\n  \"bookingDate\": \"2013-05-11\",\n  \"currencyCode\": \"EUR\",\n  \"ageBands\": [{\n    \"bandId\": 1,\n    \"count\": 3\n  }]\n}\n```\n\n**Response object** ([/booking/availability/tourgrades](#operation/bookingAvailabilityTourgrades))\n:\n\n```javascript\n{\n  \"data\": [{\n    \"available\": false,\n    \"ageBands\": null,\n    \"langServices\": null,\n    \"gradeCode\": \"EARLYM\",\n    \"unavailableReason\": \"BOOKING_CUTOFF_EXPIRED\",\n    \"gradeTitle\": \"Early Morning Departure\",\n    \"gradeDepartureTime\": \"\",\n    \"gradeDescription\": \"Flight departs Las Vegas between 7am & 8am\",\n    \"defaultLanguageCode\": \"en\",\n    \"ageBandsRequired\": null,\n    \"currencyCode\": \"ERROR\",\n    \"retailPrice\": 0,\n    \"bookingDate\": \"2013-05-11\",\n    \"retailPriceFormatted\": \"\",\n    \"merchantNetPrice\": 0,\n    \"merchantNetPriceFormatted\": \"\",\n    \"sortOrder\": 1\n  },\n  {\n    \"available\": false,\n    \"ageBands\": null,\n    \"langServices\": null,\n    \"gradeCode\": \"LATEM\",\n    \"unavailableReason\": \"BOOKING_CUTOFF_EXPIRED\",\n    \"gradeTitle\": \"Late Morning Departure\",\n    \"gradeDepartureTime\": \"\",\n    \"gradeDescription\": \"Flight departs Las Vegas between 9:45am & 10:45am\",\n    \"defaultLanguageCode\": \"en\",\n    \"ageBandsRequired\": null,\n    \"currencyCode\": \"ERROR\",\n    \"retailPrice\": 0,\n    \"bookingDate\": \"2013-05-11\",\n    \"retailPriceFormatted\": \"\",\n    \"merchantNetPrice\": 0,\n    \"merchantNetPriceFormatted\": \"\",\n    \"sortOrder\": 2\n  },\n  {\n    \"available\": false,\n    \"ageBands\": null,\n    \"langServices\": null,\n    \"gradeCode\": \"EARLYA\",\n    \"unavailableReason\": \"BOOKING_CUTOFF_EXPIRED\",\n    \"gradeTitle\": \"Early Afternoon Departu

# --- truncated at 32 KB (1013 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/viator/refs/heads/main/openapi/viator-merchant-api-v1-openapi.json