Congratulations – you’re one big step closer to going live with your Viator API integration, with only one more step left!
Before moving to production, your implementation must complete our certification step in order to ensure data integrity and appropriate use of API services.
This questionnaire is used for the back-end checks and questions asked here are used to verify the correct usage of API endpoints as described in the API documentation and in the certification documentation (Adherence to endpoint usage rules).
How to get started
Please download the form below and fill in your answers
We will verify your integration and ensure everything is in working order
We will reach out directly to you via email with additional questions or to let you know you’ve completed the back-end checks.
Back end checks document (preview)
- Please tell us which endpoints are used in your implementation. For the endpoints used, please indicate whether they are used for ingestion or in real-time, as well as how often you’re going to call them.
Please refer to this section of the API documentation: Update frequency.
For example, if you ingest all data with /products/modified-since every 30 minutes, the input in the table should look like this:
Endpoint Ingestion Real-time Additional notes /products/modified-since Every 30 mins
Please provide this information in the table below for all endpoints that are used:
- Please share a diagram or a write up of your booking flow with endpoints used in the booking process.
- Do you provide search results to customers that are returned by our search endpoint or do you return search results directly from your database?
- Do you use attraction data from the API (/v1/taxonomy/attractions)? If so, could you confirm that it’s not indexed?
- Do you display Viator or Tripadvisor reviews from the API? If so, could you confirm that this data is not indexed? Please note: guidelines to prevent indexing of unique content can be found here.
- Do you use the Viator exchange rates from the /exchange-rates endpoint? Please note: you will be invoiced (partnerTotalPrice) based on the Viator exchange rates in the currency sent in the booking request (you can choose between the following currencies: AUD, CAD, EUR, GBP, USD).
- Do you conduct availability and pricing checks in real-time prior to booking? If so, at what stage of the booking flow and what endpoint do you use for this? Can you confirm that it’s done when a specific date and passenger mix (age bands) are selected?
- Do you include customer’s contact details (email, phone) in the booking request, or your own contact details (or both)?
Please note: the email(s) address(es) provided in the booking request will be used for supplier communication in regards to bookings (i.e. pickup location, entry tickets, etc.).
- Do you support all booking questions and hotel pickup? If not, which booking questions are not supported?
- Do you have an automated process for supplier cancellations with the /bookings/modified-since endpoint? If so, could you confirm how often you’re making calls to this endpoint?
Please note: In case you’re not using the API to automate the process for supplier cancellations, you will need to rely on emails sent by Viator and ensure that travelers are informed about canceled bookings in a timely way.
- Have you implemented a timeout for API services on your end? If so, how long is it?Please note: the recommended timeout for all API services is 120s.
- Could you confirm at what stage of the booking process you’re calling the /bookings/hold endpoint? Do you verify the timestamps returned for both availability and pricing hold in the response, and make another hold in case the previous one expires?
Please note: it is important to verify the timestamps from the /bookings/hold response and make a new hold if necessary (i.e. when the first hold expired but the customer hasn’t made the booking yet) otherwise there is a risk of availability or pricing changes.
- Do you always check the booking status returned in the /bookings/book response?
Please note: even instant confirmation type products could result in rejected bookings in case of last-minute availability changes.
- Do you use the /cancel-quote endpoint every time before the cancellation is processed to verify the refund amount? Can you confirm that you check the refundAmount field?
Please note: the “status”: “CANCELLABLE” means that the booking can be canceled but it doesn’t mean that it’s refundable.
- Please share a log showing that a booking has been successfully canceled using API services.
- How many destinations do you support? Which destinations do you exclude, if any, and why?
- How many products do you support? If you filter out some products, what criteria is it based on?
- Do you support manual confirmation type products? If so, have you implemented the logic to verify the booking status via the API?
Please note: suppliers have up to 72 hours to confirm the booking request, or it will be automatically rejected 24 hours before the activity start time). If you support products with “confirmationType”: “MANUAL” or “confirmationType”: “INSTANT_THEN_MANUAL”, you need to use the /bookings/status endpoint to verify the final booking status (Viator will not send you the confirmation email) and you should have a way to inform customers about it.
- Does your platform have a valid HTTPS security certificate during all stages of the checkout process?
- Do you display the Viator/Tripadvisor logo anywhere on your site, or mention Viator/Tripadvisor in any way?
- How are you going to share the voucher with customers? Could you confirm that they will be provided only with the Viator voucher (unmodified)?
- Are you going to send your company details in the booking request (additionalBookingDetails schema) in order to display this information on vouchers? If not, how are you going to share your contact details with customers?
- Is this a B2B or B2C implementation, or both?
- Is this implementation for desktop, or mobile, or app?