Introduction

The WooDoo API has two goals:

1. To synchronize rooms inventory (availability, prices, restrictions) from WuBook to the Channel.

2. To allow WooDoo to receive reservations from the Channel

Each operation consists of a pair of messages transmitted using http or https POST requests. Data exchange format: JSON Request format: in the body of POST request The Channel will provide API endpoint URL to WuBook.

WooDoo is mainly designed for hotels. For this reason, you would notice that the nomenclature fits with the hotel domain (docs speaks about “rooms”). In many cases, this API can easily fits with Channels that are dealing with apartments, hostels, homes and other properties different from hotels.

Integration Workflow

The following steps describe the common integration workflow

Step 1: API understanding

Before any line of code, it is very important to properly understand the API and which property model it does supports. We strongly recommend you to contact us for any information or concerns. We will evaluate, case by case,when the points of incompatibility are strong enough to discourage the integration. We can also evaluate if the incompatibility could be solved with an API upgrade.

Step 2: Filling the “Channel Model Information”

Download the Channel Model Information document, fill in and send it to our channel manager devel department. It allows us to configure your connection on our side, according to your preferences.

Step 3: Implementation

You can start the API implementation if no points of incompatibility is detected.

Step 4: Testing

At the moment we can’t provide a testing environment to use during your implementation.This is because the the channel implements the server side of the API, where WooDoo is the client. For this reason we’ll do the testing after your implementation. You have to provide a test environment (test property, test endpoint) and we will test all the API functions one by one. The only exception in which you implement the client side is the push of reservations. This functionality will be the last one to be tested (you will also need credentials for BASIC authentication). In order to test the reservations integration in our system, we recommend you to create some test reservations for the property and to create different kind of them. E.G. One reservation for one room type only,another one for multiple room types, one reservation for each status (new, modified, cancelled), etc. We will fetch all these reservation and we’ll verify that the json is built correctly.

Step 5: Final issues

After testing phase, we have to agree about the procedure details in order to activate the interface for new properties.

Step 6: Beta testing

It’s possible to proceed with Beta testing phase,just after all our testings are complete and everything seems running correctly: this means to deploy the connection in the production/live environment and to activate the connection only for a few real properties.The properties will be selected among the ones that are already using both WuBook and your OTA. Is Important to be aware that they are joining a beta test so it’s possible that some inconvenience may occur (of course fixed with high priority). On our side, we are happy to offer a free trial connection of 6 months to the Beta tester,in order to compensate their effort to join the risks of beta tests and their support to verify that everything works correctly.

Step 7: Official release

After few weeks of beta testing the connection will be released for all customers. The release is preceded by an official communication shown to our customers, in the form of:

• a short news in the hompage of our extranet

• an article to our forum and blog

In order to prepare this communication, we would appreciate if you could send us some basic information about your OTA.

For example:

• which type of properties you accept (hotels, b&b, houses, apartments, hostels, etc.)

• in which countries you work and in which languages you provide support.

• all the instructions for properties that want to subscribe to your OTA (link to an online form, email,

  telephone number, etc.)

• any kind of commercial information you want to show to our customers to introduce your OTA

Room level Vs Room-Rate level availability

WuBook core model manages availability at room level. It means that if multiple rates or multiple occupancies are associated to a room, they will share the same availability. By the way, this API allows a Channel to be connected to WooDoo even if its model has availability at room-rate level, meaning that for each room the user can set different and independent availabilities for different rate plans. “Data Updating” and “Data Reading” sections have a final paragraph explaining which modifications to perform in order to implement the room-rate level availability.

Some Channels manage availability at room-rate level, but they also allow to set the same full availability for all the rates because there are policies to prevent over-bookings (for example, only one room can be booked for each reservation). In this case, we recommend to develop this API as if it was a Channel which manages availability at room level.

Base Request

Every single request sent by WuBook to the channel has the following base structure:

{
 "cm_auth": { ... },
 "hotel_auth": { “hotel_id”: “zzz”,
 ... },
 "action": "<action_name>"
 “data”: { ... }
}

Field	Mandatory	Type	Description
cm_auth	No	Dictionary (Object)	If you need to authenticate the channel manager,you have to provide us the credentials and expect them to be specified in in this field. For example: { “username”:”xxx” , “password”:”yyy” } If you don’t need authentication, this field will be omitted.
hotel_auth	Yes	Dictionary (Object)	Contains all the parameters required to authenticate the property. WuBook require at least an hotel_id, but other parameters could be required by the channel.
hotel_id	Yes	String	Unique identifier of the property
action	Yes	String	Unique identifier for the action requested by WuBook
data	No	Dictionary (Object)	Dictionary containing information to manage the request

In the following section describing the different types of requests, the Base Structure is omitted, and only action and data keys are explained.