Test harness instructions

The test harness is designed to make it easy for developers to understand the operations of the supplier API, and it provides functionality to make mock-calls to the supplier's own API endpoints with JSON or XML requests.

The test harness is a relatively simple web form that sends a JSON or XML request to the API endpoint URL that the user provides. Then, the JSON or XML response is formatted and displayed on screen.

Viator has a simple 'Test Supplier System' available that replicates the functionality of a typical tour reservations system. The endpoint URL for this system is that which is displayed by default for each service. Once you have experimented with this test endpoint, you can replace the URL with that of your own to test the requests against your code.

The Test Supplier System has been loaded with a number of products, each with several product options. These can be seen in the response from the Tour List service. Note that some tours include a SupplierOptionCode and some have additional Option Name/Value pairs. This is to help you understand how we can map Viator's product codes and product option codes to a supplier system's tour identifiers.

The test harness request and response examples are available here: http://supplierapitestharness.viatorinc.com/

Experimenting with the test harness

Basics

To get an idea of how the test harness works, start with the Availability API.

Reset one of the examples and click Submit API. Then, look further down the page to see the response. You can edit the request to change the dates or try another product by changing the values of the SupplierProductCode, SupplierOptionCode and Option Name/Value pairs. You can find sample values for these from the Tour List API.

Booking

  1. Select a product and date by noting an available SupplierProductCode, SupplierOptionCode and Option Name/Value pairs using the Availability API
  2. Enter these values into the Booking API request JSON, along with a BookingReference, which represents the Viator booking reference that will get passed through with the booking request (any number is acceptable for testing purposes).
  3. Press Submit API and check to see if the request was successful. An error may occur if the product could not be found or that there is no availability; i.e., the product has been booked out.
  4. If successful, take note of the SupplierConfirmationNumber and the BookingReference (which you previously entered). These can be used to test amendments and cancellations.
  5. You can now use the BookingReference and SupplierConfirmationNumber in requests to the Booking Amendment and Booking Cancellation requests; for example, adding a traveller or changing the date.
  6. Once you've successfully amended the booking, try cancelling it with the Booking Cancellation service.

If you've succeeded with the above experiments, you're ready to start coding your endpoint. You can change the endpoint URLs in the test harness to those of your system and start developing responses. The site is coded in PHP, can be run with Apache/PHP and does not require a back-end database, as the settings are saved in cookies on the user's browser. Feel free use the code as a basis to aid in your development efforts.

Note:

We require all suppliers to support the following APIs:

If you want to reset the test harness to it's original state, just clear your browser cookies for the domain it is hosted on.