Test Harness Instructions

The test harness is designed to make it easy for developers to understand the operations of the API, then to call their own endpoint with some sample XML requests.

The test harness is a simple web form that posts the request XML to the API Endpoint provided for each API call. The return XML is formatted and displayed on the screen. Viator has built a simple Test Supplier System to replicate the functionality of a typical tour reservations system. This endpoint is the default for each API. Once you have experimented with this endpoint, you can replace the API Endpoint with your own system's URL to test the requests against your code.

The Test Supplier System has been loaded with a number of tours, each with several options. You can view the Viator Sample Product Mappings Spreadsheet (available on the Documentation Page to see the structure of the tours and options in the example. These can also be seen by viewing the results from the Tour List API below. Note that some tours have SupplierOptionCode and some have additional Option Name/Value pairs. This is to help you understand how we can map Viator's tour codes and tour grade codes to a supplier systems tour identifiers.

Time to Experiment

  1. To get an idea of how it works, start with the Availability API. Simply Reset to one of the examples and press Submit API. Scroll down to see the response. You can edit the request to change the dates or try another tour by changing the values of the SupplierProductCode, SupplierOptionCode and Option Name/Value pairs. You can get some sample values for these from either the tour list API or from the sample mappings XLS file on the Documentation page.
  2. Let's try a booking. Select a tour and date by noting an available SupplierProductCode, SupplierOptionCode and Option Name/Value pairs using the Availability API. Then enter these values into the Booking API XML along with a BookingReference (this represents the Viator Booking ID that will get passed through with the booking request - any number will do). Press Submit API and check if it was successful. It may show an error if the product could not be found or that there is no availability if it was booked out. If successful, note the SupplierConfirmationNumber and the BookingReference (which you previously entered). These can be used to test amend and cancel.
  3. You can now use the BookingReference and SupplierConfirmationNumber to update the Amend and Cancel requests. Give them a go. Maybe add a traveller or change the date. Then once you've successfully Amended the booking, try to Cancel it.
  4. If you've succeeded with the above experiments, you're ready to start coding your endpoint. You can change the endpoints in the Test Harness to point to your system and start developing responses. If you wish to develop with an internal endpoint address, please please let us know and we can send the latest version of this Test Harness to you to run on your internal systems. It's written in PHP and does not require a database as the settings are simply saved in cookies on the user's browser. You just need Apache/PHP to run it. You can even hack it to aid in your development efforts.
  5. We'd like to see all Suppliers support at least the Availability (unless your activities are 100% freesale - ie: Themepark) and of course the Booking API. You can also support the Amend, Cancel and others if you wish as these will save your Reservation Team a lot of time and energy.

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.