Room List

The method allows WuBook to read the hotel rooms from the channel extranet.

Request from WooDoo

"action": "get_rooms"

“data” is not specified

Response from channel

{
"code": 200,
"data": {
“hotel_id”: “100”,
"rooms": [
  {
   "room_id": "1",
   "name": "Standard Single",
   "room_occupancies": ["occup_id_1"]
   "type": "room",
   "max_avail"= 1,
  },
  {
   "room_id": "2",
   "name": "Standard Double",
   "room_occupancies": ["occup_id_1", "occupancy_id_2"]
   "type": "bed",
  }
 ],
"occupancies":{
     “occup_id_1”: “occup_name_1”,
     “occup_id_2”: “occup_name_2”,
  }
 }
}

Field	Mandatory	Type	Description
rooms	Yes	List	List of rooms. At least one.
room_id	Yes	String	Unique identifier of the room in the property
name	Yes	String	Unique room name
room_occupancies	No	List	List of strings representing occupancies for the room.
type	No	String	Possible values: “room”, “bed”. Default is “room” if the field is missing. Ignore this field if your model expects only type “room”.
max_avail	No	integer	Include this field if the room accepts a maximum value of availability. Updates of higher values should not generate errors, but automatically reduce the updated value to the max_avail limit. Ignore this field if the room has not upper limit for availability (missing field means “no limit”.

Occupancy Model

For your connection with WooDoo, you can choose between one of the following models, accordingly to your way to manage prices for room occupancies.

1) No occupancies

If your system doesn’t support different rates for a different number of guests, the room_occupancies and occupancies fields must be omitted.

2) Simple occupancy model

A common and simple way to manage occupancies is to represent the occupancy with aninteger which stands for the allowed room occupancy. E.g. A triple room could be booked with occupancy 1, 2 or 3. In this case, the room_occupancies field should be a list of integer (cast to string). Occupancies field can be omitted. For example, for a triple room which supports also single and double use,the get_rooms call should return:

{
 "room_id": "2",
 "name": "Triple Room",
 "room_occupancies": [ "1",“2”,“3” ]
}

3) Advanced occupancy model

Some Channels are using a complicated occupancy model,where a specific occupancy can be split in different occupancies.

For example, occupancy 3 could be split in 2 different occupancies:

• 3 adults

• 2 adults + 1 child

WooDoo API supports also a different occupancy model. A new occupancies field should be returned in get_rooms service. It is a dictionary (Object) in which key is an occupancy identifier and value is the corresponding full name. Using the same example above,get_rooms should return:

rooms:[{
    "room_id": "2",
    "name": "Triple Room",
    "room_occupancies": [ “3a”,“2a1c” ]
}],
'occupancies': {
     “3a”: “3 adults”,
    “2a1c”: “2 adults + 1 child”
}

Important

• Each occupancy identifier MUST refer to a rate which represents the whole price of a bookable rom, and not just a part of it. An occupancy identifier representing just the rate for extra beds, it is not allowed. On the other hand,it is correct to set an occupancy identifier which represents the standard occupancy rate for the room plus 1 extra bed. Extra bed prices could optionally be managed through “custom fields” (see chapter Custom fields).

• Occupancy identifiers should be factorized as much as possible.This means that, for example, the identifier “pax2” which represents the rate of a room with occupancy 2, can be associated to double rooms, triple rooms, quadruple rooms, etc. You should not define a different identifier for each room type (i.e. “pax2_double”, “pax2_triple”, “pax2_quadruple”) This will prevent an “explosion” in the number of occupancies that would produce a very complicated occupancy management on WuBook extranet for the customer.