Viator Reservation System API

The API specifications herein outline the steps and requisites for integrating operator reservation systems with Viator. This documentation serves as the definitive guide for developers and technical teams responsible for implementing and maintaining this critical integration.

The specifications are for the exclusive use of operators registered with Viator and their respective reservation system providers.

Integration with a reservation system may only commence after any one operator on the reservation system has registered with Viator. To learn more about joining Viator, visit the supplier sign-up page.

To begin, please review the following sections:

• What’s new
• Connectivity overview
• API overview
• Implementation approach
• Frequently asked questions

Adherence to these specifications is crucial for successful integration, guaranteeing optimal performance, data integrity, and a superior user experience for both operators and Viator customers.

If at any point you need clarification or help, please don’t hesitate to contact us here.

This section outlines the key updates and new features in the latest version of the Operator Connectivity API specifications:

The Operator Connectivity API now uses versioning for backward compatibility and smoother updates. Existing legacy endpoints are considered version 1.0, while versions of new endpoints begin with 2.0.

To allow early access and feedback on upcoming endpoints before release, a Beta program has been introduced. This allows partners to evaluate pre-production versions. Review the Beta section for newly introduced endpoints.

As new versions of the endpoints are introduced, older versions and endpoints that were replaced are set for deprecation.

Review the Deprecated section for a list of endpoints scheduled for deprecation.

Version 2.0 and above endpoints now expose the API key on the HTTP headers. Backward compatibility for legacy v1 endpoints continues to be supported, no changes required at this point, but header key authentication is also supported on v1 endpoints.

Version 2.0 and above endpoints communicate using the JSON standard. Therefore, the headers "Content-Type" and "Accept" accept only "application/json".

A simplified product variant (aka product option) identifier has been introduced to allow reservation systems to define a unique single identifier to identify any product variant. This new identifier is applicable only to v2.0 API's and must be returned in the Tour List API.

One of the most impactful changes with the new version is the introduction of pricing capabilities that support all of Viator's existing pricing models, including per person price, tiered per person price and unit price.

Version 2.0 introduces new Viator hosted endpoints that enable reservation systems to communicate updates to Viator regarding:

• Salability (availability status)
• Capacity (remaining seats or spaces)
• Pricing (current rates)
• Special Offers (discount merchadising)

These endpoints ensure that customers always see accurate, current, inventory and pricing as provided by operators through reservation systems.

Version 2.0 introduces a new endpoint that allows Viator to request for the reservation of inventory and price before the booking is made. In V1.0 inventory was held via the Real-time Availability API request using the AvailabilityHold attribute. In V2.0, this process has moved to the new endpoint that now also expects pricing to be held.

For version 2.0 APIs a contract testing tool is available to help ensure that services are performing according to specification. The tool provides multiple test cases, along with parameters required to perform the tests, for each API. For more information review the Contract Testing Tool section under Contract Testing.

1. Project Kick-off Meeting - Scheduled by Viator technical resources after initial contact with the Supplier. The following should be discussed:

• Determine Project Team Members
• Scope of Implementation (capabilities to be supported)
• Agree on Preliminary Time Lines
• Determine Project Team Communication Method

2. Specification Review and Data Mapping - Reservation systems review API specifications in preparation for development. This steps includes:

• Review of API specifications
• Mapping API fields to reservation system fields
• Mapping API product structure

3. Specification Clarifications - Reservation system will raise clarifications with Viator.

• This can be done via email or phone.

4. API Development - Reservation system will commence development of the necessary APIs. This includes:

• Development of reservation system services
• Development of Viator service requests
• Contract testing

5. Test Environment Configuration - Viator will configure the test environment in preparation for certification testing. This step includes:

• API configuration
• Product mapping

6. Certification Testing - Reservation system and Viator will conduct various certification tests to ensure APIs are working as expected. This step includes:

• Agreeing on test products
• Agreeing on a test schedule
• Test Execution and reporting (typically over email)

7. Production Environment Configuration - Viator will configure the production environment. This step includes:

• API configuration
• Product mapping

8. Go Live - Viator and reservation system prepare for Go Live. This includes:

• Schedule Go Live date
• "Switch On" the API, initially for a small number of products
• Transaction monitoring and issue resolution
• Roll out all applicable products
• Sign-off by reservation system and Viator

Integration with the Viator Reservation System API presents considerable strategic benefits for operators and reservation systems. It substantially enhances distribution and sales capabilities by furnishing Viator with a more comprehensive inventory and real-time transaction capabilities.

API integration with Viator is essential for accommodating last-minute bookings, allowing operators to sell remaining inventory until their specified booking cutoff. Furthermore, the API automates availability and pricing synchronization and booking transactionsto that lead to higher accuracy and reduced operator overhead.

The API's primary functionalities encompass:

• Pricing and availability synchronization with capacity administration
• Departure time synchronization
• Booking reservation and confirmation
• Post-booking transaction automation

Additional advantages of API integration include:

• Streamlined Reconciliation: The Viator booking confirmation number is sent to the operator's reservation system via API. This number, along with the operator's confirmation or order number, is displayed on Viator customer vouchers/tickets, allowing for booking reconciliation within the operator's reservation system.

• Barcode Compatibility: The API allows reservation systems to generate barcodes that can be integrated into Viator customer paper or smartphone vouchers/tickets. This functionality is particularly important for operators who use barcode scanners for activity entry.

• Product Identification: Viator customer vouchers display the operator's product identifiers, which are correlated with Viator's own identifiers. This correlation allows operators to have a clearer identification of the product purchased by the customer.

This section provides details pertaining to the API supported business processes, security, communication, testing, and implementation. Achieving integration with Viator the use of both Viator and supplier built APIs:

• Reservation System APIs: Services developed by the reservation system / booking software and consumed by Viator.
• Viator APIs: Services developed by Viator and consumed by reservation systems / booking sofware.

This document provides detailed specifications for each service along with testing tools and migration guides, establishing a standard for integration with Viator.

The Viator Reservation System APIs have been designed to support a number of business processes, these include:

• Product validation and mapping - supported by the Tour List API.
• Price and availability synchronization - supported by the Availability and pricing APIs.
• Special Offer Merchandizing - supported by the Special Offers API and Special Offers Notification Webhook
• Reservation and booking - supported by the Reserve and Booking APIs.
• Post booking transactions - supported by the Booking Amendment and Booking Cancellation APIs.
• Redemption verification - supported by the Redemption API.

All APIs will use the Hypertext Transfer Protocol Secure (HTTPS).

Authentication is achieved by the use of API keys, supplied within the header (v1.0 and v2.0 endpoints) or the payload (v1.0 endpoints only) of each request. A unique API Key is assigned for each Operator account.

The Viator Reservation System APIs support RESTful architecture. JSON and XML (for v1.0 APIs only - scheduled for deprecation) formats are supported.

All RESTful APIs use POST methods only, GET, DELETE, PUT, etc. methods are NOT currently supported. The message body of the POST request/response will include the payload described in this document.

The following sections detail the operational impact of integration and endpoints on overall connectivity, operator processes, and customer experience.

The API structure is organized into three primary categories:

• Catalog operations
• Availability and pricing
• Booking operations
• Booking redemption

Tour list

The Tour List API streamlines the mapping of an operator's reservation system inventory (products and product options) to Viator's equivalent. These mapped values are then used in subsequent transaction requests, where Viator transmits requests using the reservation system's identifiers.

The details returned in the Tour List API are surfaced in the Product Connection tab of the Viator supply center to facilitate accurate inventory mapping between the two systems.

Mapped inventory must have capacity (available for sale). If a product cannot be mapped, there is likely a problem with the Tour List API response or with the inventory capacity (not available for sale, issue with availability api’s response). The technical team at the reservation system is typically better equipped to resolve such scenarios.

Support for the following APIs is a mandatory integration requirement, highlighting their fundamental role in efficient inventory and pricing management for operators, and overall impact to the customer booking experience.

Integrating our comprehensive suite of availability and pricing APIs revolutionizes how operators manage availability and pricing of their inventory, significantly reducing the need for tedious manual updates within the management center. This powerful collection includes a set of distinct APIs, each tailored to streamline specific aspects of the operations and customer experience:

• Calendar API (v2.0) - Empowers Viator to access and retrieve long term availability, pricing and special offer (promotions) information from the reservation system. This allows Viator customers to view available dates and prices on the product details page calendar. For operators, these APIs automate the regular updates of availability. Pricing and special offers, eliminating the need for manual intervention through the Viator supply center. This API replaces both the Batch Availability and the Batch Pricing APIs (both of which are v1.0).

• Availability Check API (v2.0) - Designed for real-time usage through the booking flow, this API enables Viator to verify capacity (availability for sale) in real-time throughout the customers progression through the booking funnel. This ensures that customers always see the most current availability and pricing information, preventing overbookings, erroneous customer charges, encouraging last minute bookings and enhancing the overall customer experience. This capability is crucial for supporting operators' dynamic, fluctuating pricing strategies and responding instantly to market demands. This API replaces the Real-time Availability API (v1.0).

• Event Notifications (v2.0) - This critical endpoint hosted by Viator provides reservaton systems the ability to notify Viator when changes are made to pricing, or when changes occur to capacity and availability. This not only ensures Viators pricing always reflects the operators desired price, it enables Viator to allow or prevent over bookings and is expecially important to drive bookings for last minute availabilty.

• Special Offer Notifications (v2.0) - This endpoint allows for the notification of new or updated Special Offers to Viator, ensuring that Viator accurately merchandises discounted inventory. The updates provide merchandising signals for customers, increasing the visibility of the offers and thereby boosting bookings.

• Special Offers API (v2.0) - Retrieves the Special Offers metadata required for Viator to accurately apply special offer rules and provides operators with visibility into the merchandising signals associated with their inventory.

By leveraging these APIs, you can automate a significant portion of operational tasks, leading to improved accuracy, reduced operational overhead, and a more responsive and efficient system for managing availability, pricing and special offers. This automation not only streamlines operators internal processes but also enhances the customer experience by providing up-to-date and reliable information.

The following booking operations APIs are available and, with the exception of the booking amendment API, are mandatory to support:

Reserve

The Reserve API (v2.0) is designed to hold inventory and price for a booking.

This API supersedes the InventoryHold function previously available in the Real-time Availability API (v1.0). Viator requires reservation systems to hold inventory for a specific duration, facilitating a seamless customer experience by allowing adequate time for payment completion during checkout. This mechanism helps operators avoid overbookings while also preventing inventory from being held unnecessarily. Reservation systems are encouraged to release previously reserved inventory if a booking is not confirmed within a predefined duration.

This API must only be used in combination with Availability and Pricing v2.0 APIs.

Booking

The Booking API creates a booking in the operator's reservation system upon successful customer payment. This transmission finalizes the booking process.

Operators are not notified via email when a booking is successfully transmitted by the API. However, if an API booking attempt in unsuccessful, the booking fallback process is initiated, which then notifies operators of bookings via email.

Booking Amendment

The Booking Amendment API allows changes to confirmed bookings to be sent to the operator’s reservation systems. Customers can request booking amendments after payment and booking confirmation, but before travel.

Permissible amendments:

• Lead traveler's name
• Traveler mix
• Travel date
• Hotel details
• Tour option

Operators will receive booking amendment email notifications only if an API booking amendment attempt is unsuccessful. Successful API booking amendments do not generate email notifications for operators.

Booking Cancellation

The Booking Cancellation API streamlines the cancellation and refund process for confirmed bookings. It automates the cancellation request by transmitting it directly to the operator's reservation system. This not only minimizes administrative tasks for operators but also guarantees precise inventory representation, facilitating the resale of tickets.

Operators will receive booking cancellation email notifications only if an API booking cancellation attempt is unsuccessful. Successful API booking cancellations do not generate email notifications for operators.

The Booking Redemption API provides Viator visibility into the redemption status of a confirmed booking at the time a customer makes a cancellation request to ensure refunds are processed accordingly.

Configurations must be determined and applied to both Viator and reservation systems to enable communication via the APIs. The following configuration items must be determined during the project initiation phase:

• Integration capabilities - provided by the reservation system, these are the APIs support by the reservation system (including mandatory API's).
• Reservation system endpoints - provided by the reservation system for each of the services supported.
• Supplier ID - provided by Viator in preparation for testing, the SupplierId uniquely identifies an operator in Viator systems
• Reseller ID - provided by Viator (for v1.0 APIs only) in preparation for testing.
• API key - provided by Viator in preparation for testing and Go Live. the API key is used for authenticatication

Viator systems will make API requests to the reservation systems using the reservation systems product identifiers. The reservation system product identifiers are typically provided to Viator via the Tour List API. These are mapped to Viator products so that subsequent transactions utilize the reservation system product identifiers.

The API supports multiple fields that can be used to identify products and product options (aka product variants), i.e., a product option typically has either different pricing or inventory levels from other options of the same product.

In the APIs the following fields can be used as identifiers of products and/or product options. The supplier determines which of the below fields it needs to use to correctly interpret what product or product option an API request is for.

• SupplierProductCode – this is the only mandatory product identification field in Viator APIs. It is meant to be used for a code (key) that uniquely identifies a product.
  • Note: this field has a maximum length of 50 characters or less and must not include the pipe (|) character; product codes longer than this will fail.
• SupplierOptionCode – this field is optional. It is used when a product has multiple options, it identifies an option (or a variant) of the product.
• Name/Value - a max of four key/value pairs can optionally be used in conjunction with the SupplierOptionCode to uniquely identify a product variant. These appear under the Option element in the APIs. Similar to SupplierOptionCode they can be used to identify an option.
• productOptionId - this field has been introduced with v2.0 and is applicable only to v2.0 APIs. It is a singled identifier for the product variant. This identifier will in the future replace SupplierOptionCode and Name/Value fields.

Viator currently only supports a limited group of pricing rates: Adult, Child, Youth, Infant and Senior. Reservation Systems and operators may support other pricing rates.

We recommend the following mapping of various pricing rates to Viator supported options.

Reservation System Price Rates	Viator Price Rates
Adult	Adult
Child	Child
Youth	Youth
Infant	Infant
Senior	Senior
Concession	Senior
Veteran	Senior
Pensioner	Senior
Student	Youth
Teenager	Youth
Toddler	Infant
Baby	Infant
Everyone	Adult
Other	Adult
Family Price.	Not Supported

Viator alse supports the concept of unit pricing. For products priced in this manner the following is recommended:

Reservation System Price Rates	Viator Price Rates (Age Bands)
Car	Unit
Boat	Unit
Vehicle	Unit
Group	Unit

The booking cut-off value is a time, prior to a sellable item's start time, after which booking may no longer be accepted by the reservaon system; for example, a particular tour might not accept bookings if it is less than 24 hours before the start time.

For connected products, this value is provided to Viator via the bookingCutoff element of the Availability and pricing API responses.

BookingCutoff Usage

The bookingCutoff will be used to prevent bookings from take place after the time specificed in the bookingCutoff. It is also used to inform customers how long they have left before a booking cut-off restriction prevents them from booking. This aims to both drive customers to make a purchase and improve the customer experience by minimizing unexpected booking failures.

Viator and integrated reservation systems must guarantee a target API availability of:

• For critical, synchronous APIs like Real-Time Availability and Booking and also for Viator Inbound APIs expected target of 99.8%. It will be an acceptable target of 99.5%.
• For APIs where usage is asynchronous (e.g., batch data synchronization) and therefore the business impact of temporary availability loss is less severe compared to synchronous booking operations, a target of 99.5%. It will be an acceptable target of 99%.

Viator's proposal acknowledges that APIs used in real-time are inherently more critical and thus require stringent (tighter) latency targets. Conversely, data-sync APIs can be assigned more relaxed latency targets, reflecting their lower impact on immediate user interaction and conversion. The following table presents the latency targets, broken down by APIs.

APIs	Expected P90 (secs)	Acceptable (secs)	Longest Allowed (secs)
Availability Check	< 1	3	10
Reserve	< 1	3	28
Booking (includes amendment, redemption and cancellation)	< 5	10	28
Calendar	< 5	10	20
Tourlist	< 10	15	60

For Viator inbound APIs the latency targets are:

APIs	Expected P90 (secs)	Acceptable (secs)
Event Notification API Beta	< 1	2
Special Offers Notification API Beta	< 1	2

The following table describes the API Types and the respective maximum error rates.

API type	Maximum acceptable error rate (Monthly)
Availability Check	< 1.5%
Reserve	< 1.5%
Booking(includes amendment, redemption and cancellation)	< 0.75%
Calendar	< 1%
Tourlist	< 0.5%

For Viator inbound APIs the error targets are:

API type	Maximum acceptable error rate (Monthly)
Event Notification API Beta	< 0.5%
Special Offers Notification API Beta	< 0.5%

To ensure system stability, Viator and the Integrated Reservation System agree to the following throughput limits. These are calculated based on the total number of connected products to ensure the infrastructure scales alongside the business.

Throughput Calculation Logic

Capacity is determined by a Product Multiplier (𝑿), defined as:

• 𝑿 = Total number of connected products, divided by 10,000 (rounded up to the nearest ten thousand).
• Minimum Value: For systems with fewer than 10,000 products, 𝑿 = 1.

API	RPS (Sustainable)	RPS (Peak)
Availability Check	𝑿 x 10	𝑿 x 20
Reserve	𝑿 x 5	𝑿 x 10
Booking(includes amendment, redemption and cancellation)	𝑿 x 5	𝑿 x 10
Calendar	𝑿 x 30	𝑿 x 60
Tourlist	𝑿	𝑿 x 2

For Viator inbound APIs the throughput targets are:

API	RPS (Sustainable)	RPS (Peak)
Event Notification API Beta	𝑿 x 10	𝑿 x 30
Special Offers Notification API Beta	𝑿 x 2	𝑿 x 4

Example for Availability Check: RPS (sustainable) = 𝑿 x 10, RPS (peak) = 𝑿 x 20

Total Products	Multiplier (𝑿)	RPS (Sustainable)	RPS (Peak)
1 - 10,000	1	10	20
15,000	2	20	30
42,000	5	50	100

Below is the descriptive table outlining the Viator Proposal for Mean Time To Acknowledge (MTTA) and Mean Time To Recovery (MTTRs) for Reservation and Viator systems. The values presented are contingent upon the Severity Level and the resulting business impact.

Severity Level	Reservation System (Business Impact)	Viator (Business Impact)	Target MTTA (business days)	Target MTTRs (business days)
S1 - Critical Outage	Reservation system unreachable or core endpoints inaccessible to all the suppliers	Endpoints unreachable; Impact on all of the reservation systems	< 2	< 5
S2 - Major Disruption	Supplier segment impacted; Real time capabilities impacted; Supplier Authentication issues;	Supplier segment impacted; Authentication issues;	< 3	< 14
S3 - Moderate/Low Impact	Supplier segment impacted; Non real time capabilities impacted; Minor bug, SAPI API, or general question/request; minimal impact on core services.	Contract testing: Certification testing process; Minor API inconsistencies.	< 5	< 90

The Beta section introduces new endpoint versions, offering our Beta partners early access to features for review and prototyping. Developers can use these Beta endpoints to speed up adoption and to provide feedback on API functionality and usability.

Whilst intended for production release, these APIs may undergo modifications during the Beta phase if critical issues are identified. Developers may need to adjust their implementations if a change is deemed necessary. All changes to Beta endpoints will be communicated to Beta partners.

Please email the API integrations team to provide feedback.

This section describes all of the possible services, some of which are mandatory, that reservation systems can developed to integrate with Viator.

All API requests made by Viator to the reservation system are specified. The reservation system will response to Viator requests in a synchronous manner, responding as per specification. Both request and response formats are described in detail in subsequent sections of this document.

This section describes the Viator built API(s) available for reservation system consumption.

Note: For these APIs, the request is sent to Viator and the response is received from Viator.

The Contract Testing Tool is a self-service tool provided by Viator to assist reservation systems testing and validating their API integration for v2 APIs (v1 APIs are not supported).

This tool is a web application (meant to be executed locally) that includes a complete suite of contract tests that enables developers to test their endpoints. Endpoints need not be exposed externally for tests to run.

Configuration and Execution

The first step is to make sure you have Docker desktop installed and running.

Then, get the values of your API Key and SupplierID (provided by Viator after the Kick-off Meeting) and set them as environment variables as follows:

export API_KEY=<your-api-key>
export SUPPLIER_ID=<your-supplierId> (e.g. 123456789)

Finally, run the Contract Testing Tool using the following commands:

docker pull public.ecr.aws/viator/cica:latest
docker run -it --rm --name viator-contract-testing -p 5173:5173 -p 8989:8989 \
  -e API_KEY=$API_KEY -e SUPPLIER_ID=$SUPPLIER_ID \
  --add-host=host.docker.internal:host-gateway \
  public.ecr.aws/viator/cica:latest

Usage

Access the application at http://localhost:5173. The tool is organized into a Configuration page for initial setup and dedicated Capability pages for executing test scenarios.

1. Pre-Execution Setup (Configuration Page)

Before running tests, use the Configuration page in the left panel to streamline your workflow:

• Global Defaults: Parameter values used as a fallback when executing test cases if values are not provided elsewhere.

• Test Product Option Mapping: Values provided here are used when executing any test case associated to the Test Product Option.

Configuration Priority: The tool resolves inputs in the following order: Test Case Input (highest) > Test Product Option Config > Global Defaults (fallback).

2. Test Execution (Capability Pages)

In the left panel, you will find a list of capabilities (e.g., AVAILABILITY). After selecting a capability, the main page will present a set of scenarios which are test cases that can be executed.

To execute a test case against a reservation system endpoint:

• Expand the test case by clicking on it.

• Fill the Capability Endpoint or the Global Endpoint (when the same endpoint serves all the capabilities) with the full URL of the API endpoint being tested.

  • Note: if you are running your api locally you must insert http://host.docker.internal:<port>/your-api-path instead of http://localhost:<port>/your-api-path as the contract testing tool is running on docker.

• Fill the form inputs required by the scenario being tested.

• Click on Execute Test and view the Test Report.

To execute a test case against a Viator endpoint (e.g. Event Notification):

• Send a request to the endpoint displayed in the tool from your local/test system.

• Expand the scenario to view the test result.

The following outlines the essential steps and considerations for migrating to the v2 pricing and availability endpoints. Adhering to these requirements will ensure a smooth transition and maintain data integrity.

The following table describes the v1 endpoints that will be superseded by the respective v2 endpoints.

v1	v2
Real-time Availability API	Availability Check API
Batch Availability API	Calendar API
Batch Pricing API	Calendar API
Availability Notifications (2) API	Event Notifications API
N/A	Special Offers Notifications API
N/A	Special Offers API

Before initiating the migration, ensure the following prerequisites are met:

• Development: All v2 endpoints and call backs must have been developed according to the specifications and thoroughly tested, including successfully passing applicable contract tests. The productOptionID must be introduced in the Tourlist API.

• Certification: Your integration must have successfully passed certification testing.

• Notification Endpoints: The new notification endpoints are accurately configured as documented in the specifications.

• Viator operator account configuration: The operator accounts must be configured with the new endpoints for v2 access on Viator.

• Reservation System operator account configuration: The operator account must be configured to utilize v2 endpoints in the reservation system.

The migration of operator accounts to v2 APIs will take place in two separate phases:

1. Pilot accounts

   • Viator and the Reservation System will jointly select a small number of operator accounts for the initial migration.

   • The chosen accounts will first be configured in the Viator sandbox environment. This step is dedicated to verifying transactions, pricing, and availability to identify any potential inconsistencies and ensure a smooth subsequent production roll out

   • Following successful validation tests in the sandbox, the accounts will be configured in both Viator and the Reservation System to enable v2 functionality in the production environment.

2. Main Rollout

   • After the successful pilot account rollout, Viator will determine and inform the size and sequence of operator account batches for production rollout.

   • A cooling-off period will be observed between each sequential batch to monitor system performance.

   • For each batch, Viator and the Reservation System will coordinate to configure accounts for v2 production enablement.

• All superseded v1 endpoints (see “Deprecation” section for details) must remain operational throughout the migration period and until a future end-of-life procedure is agreed. This will ensure a smooth transition and facilitate a roll back should any issues be encountered.

• v1 Availability (2) Notifications must continue to be sent in parallel to v2 Notifications until an account is fully migrated. Viator ignores notifications that do not apply.

Upon completion of the migration of all Operator accounts to v2 endpoints, Viator will inform the reservation system to allow for deprecation procedures to commence.

The following steps can be completed once the confirmation is received:

• Disable all notification to Availability Notifications (2) API

• Disable the following endpoints:

  • Real-time Availability API
  • Batch Availability API
  • Batch Pricing API

For any questions or assistance during the migration, please contact the API integrations team or refer to the FAQ section in these specifications.

Q: If we use the API, how do suppliers control the inventory available to Viator?

A: Suppliers retain control of the inventory they expose to Viator. The API simply replaces the manual work of inserting bookings into your system and providing blockout information to Viator. Suppliers still control the inventory that they want to sell to Viator.

---

Q: Does the API contain pricing and payment information?

A: Viator is the credit card merchant of record for all transactions – no payment information needs to be processed by the supplier or supplier’s system. We do not send credit card information via the API. The supplier net rate and pricing information is stored on Viator's side and can be updated via the Availability and pricing APIs; or, through the regular process of updating the Schedule and prices tab in the Supplier Extranet.

---

Q: How can non-Viator suppliers use the Viator API?

A: If you have suppliers that are not working with Viator today, please refer them to the Supplier Sign Up link on Viator.com. The Viator API will only work with current Viator suppliers, but we are always looking for new and exciting products to offer.

---

Q: How do we map our internal product codes to Viator’s product codes?

A: At the commencement of the project, Viator will provide a list of the supplier's products and product options. Together, we can then define a mapping approach between Viator's and the supplier's systems. This is a critical part of the project, as we need to ensure that the mapping values correctly identify the variables that have an inventory concern.

Mapping is carried out either by the supplier or the administrator of the reservation system. Viator's mapping feature is available via the Supplier Extranet. The mapping wizard utilizes data from the Tour List endpoint.

Common questions regarding the booking information that is sent:

Q: Will I receive the customers direct email address?

No, due to company policy, we will never provide the customer's real email address. However, you have the option to have the same obfuscated email address that is currently hidden behind our “Contact Customer” button in the management center to be sent to you.

This is an optional feature that your developers can accommodate, and it will place the obfuscated email address directly into your reservation system so your reservations team does not need to log into our management center to send the customer an email.

The added benefit is that communication between you and the customer is logged in the booking history notes, should you need it for future reference. This email address is valid for 30 days after the travel date.

Q: Will I receive the customers direct phone number?

Yes, if the customer completes the phone number field on our checkout page, tit will be included in the booking information. Note, however, that not all partners support this field.

Q: Will I receive the customer's hotel information?

Yes, if you currently have the hotel pick up box activated for your products, the customer will be able to select their hotel from the drop down menu and this information will be sent to you in the “Pick up point” field.

If you are currently collecting this information from the special requirements field, the “Special Requirements” field will be populated with this information.

Q: Will I still receive the information that a customer enters during the booking process such as flight and cruise ship information?

Yes, this information is passed in the question and answer fields of the booking request.

Q: How to do I correctly handle the product's guide language when it is an inventory concern?

For operating languages with limited capacity, such as a Portuguese guided tour, it is essential to accurately return the product option in the Tour List API. This facilitates the mapping of the equivalent Viator product option to the operator's system, allowing for capacity verification during booking.

However, if the operator provides audio or written language guides without capacity limitations, including product options of language in the Tour List API is not necessary. The audio guide language chosen by the customer at checkout will be transmitted with the booking request.

Q: When should I use SupplierOptionCode and how does this affect the product set-up?

The SupplierOptionCode serves as a unique identifier for various product options or variants. It can be paired with Name/value pairs to specify different versions of a product. For instance, a dinner cruise might offer "window seat" and "best available" as distinct options.

Q: Should I support barcode numbers or pass-through tickets? The answer is based on how operators expect customers to check-in to the tour or activity. There are two possible options:

Using Viator standard vouchers. These can include a per-traveller barcode (TravellerBarcode) or a per-booking barcode (TourBarcode) returned from the operator's reservation system in the Booking API. The use of per-traveler or per-booking is confirmed by product in Viator's supply center. Using the operator’s reservation system ticket, returned in the Booking API TourTicket. With this option, the Viator ticket will be suppressed, and customers will receive the provided ticket. This option cannot be controlled via Viators supply center; please contact us if this is desired.

Q: What is the relationship between 'start times' and the API?

The following is applicable to legacy v1.0 Availability and Pricing APIs only.

Our management center provides you with different time options to accommodate different product types, such as opening hours and start times.

However, for the API connection, if the starting time that the customer selects is important for you to know in the booking details; or, if there is an inventory concern, you must return the TourDepartureTime tag as a mapping value and do not include the start time as part of the SupplierOptionCode.

In the management center, you will then be restricted to using only the 'start times' option. The reason for this that the starting time information in the management center synchronizes with the information in the TourDepartureTime field, and this information is then presented to the customer on our site.

Example of start times syncing on the product connection tab:

This appears to the customer as:

All starting times listed on the product connection page that have been synchronized will be displayed to the customer. If a particular starting time is not available, that time will appear crossed-out.

The benefits of using the TourDepartureTime tag include:

Eliminating the need to identify each start time as a product option

• This saves your team time by obviating the need to create new product options in the management center. This also saves the SupplierOptionCode for when it is genuinely required to differentiate between the product options.

• The availability for each individual time can be checked, and the customer will be able to select their preferred time during the booking process instead of contacting you directly to arrange a time post-booking (but prior to travel).

Note: If there are any changes made to the Time option in the management center; for example, changing from start times to opening hours, this will break the API connection unless the TourDepartureTime is also removed from the API response.

Please email the API integrations team with any questions or suggestions. A ticket will be logged with the team who will respond as quickly as possible.

This section lists endpoints that are no longer recommended for new or updated integrations and are scheduled for removal. These endpoints remain available for existing connections only and will stop receiving new features or behavior improvements at any time.

For all new development, use the current, fully supported endpoints documented in the main sections of this guide.