Handling Reservations

Wired makes possible to insert new reservations and to cancel existing ones. To do that, you just have two functions:

cancel_reservation(token, lcode, rcode[, reason= '', send_voucher= 1])
confirm_reservation(token, lcode, rcode[, reason= '', send_voucher= 1])
reconfirm_reservation(token, lcode, rcode[, reason= '', send_voucher= 1])
new_reservation(token, lcode, dfrom, dto, rooms, customer, amount[, origin= 'xml', ccard= 0, ancillary= 0, guests= 0, ignore_restrs= 0, ignore_avail= 0])

cancel_reservation() is used to cancel an active reservation. confirm_reservation() is used to confirm a reservation waiting for confirmation reconfirm_reservation() is used to reconfirm a reservation previously deleted. Notice that it’s not possible to modify reservations originated by OTAs. You can just modify direct reservations (received via the wubook’s booking engine). The reason parameter is just a string and acts as a remark while send_voucher determines if Wired should send a voucher to the customer or not.

The new_reservation() function is used, instead, to insert new reservations. Combined with the WuBook Fount - Selling rooms on your site, it can even be used to develop a basic, but powerful and easy, booking engine.

The rooms argument is a KW structure, like this:

rooms= {
  '1': [quantity, board],
  '2': [quantity, board],
}

To better understand possible values of the board field, please, refere to the Handling Rooms section. Also the customer argument is a KV structure and it must contain the following keys: lname (last name), fname (first name), email, city, phone, street, country, arrival_hour and notes (remarks). The country parameter is the 2-digit country symbol, for example: IT,UK,FR,US,RU and so on.

The origin field is a kind of signature: this way, you can tag the reservation with an “Originated by” tag. The ccard field is used if you want to provide a CC guarantee for this reservation. It’s a KV structure with the following fields: cc_exp_year, cc_exp_month, cc_type, cc_cvv, cc_owner and cc_number. In particular, the cc_type field represents the credit card family (VISA, MASTERCARD…). It is an integer, check the following table to discover its possible values:

Family

Integer

VISA

1

MASTERCARD

2

DISCOVER

4

AMERICAN_EXPRESS

8

ENROUTE

16

JCB

32

DINERS

64

TEST

128

MAESTRO

256

BLANCHE

512

AUSTRALIAN

1024

EUROCARD

8192

UNIONPAY

16384

BOOKCOM

32768

CARTEBLEUE

65536

CARTEBANCAIRE

131072

MNP

262144

VISA ELECTRON

524288

The ancillary field is an arbitrary KV structure, where you can collect additional information.

Guests is a KV stucture containing additional people in the reservation and it’s arbitrary; guests wants two params, “men” and “children”. If used, you have to specify at least an integer for the “men” param, otherwise you’ll encounter an error.

The ignore_restrs parameter, if set to 1, will avoid restrictions like “Min. Stay”, “Min. Stay Arrival”, “Max. Stay”, etc. And the ignore_avail parameter, if set to 1, will insert the reservation even if there is no availability for the specified room(s).

Warning

Ignore Restrictions and/or Availability should be used just for specific integration cases. A bad use of these params, can cause confusion and even overbooking.

Below, you’ll find an xml example of a call followed by an answer of the new_reservation() function.

+ show/hide code