Request
The booking request is close to the availability query but contains far more details used to better describe the booking. Here is an example:
There is only one difference in the update request message. The type attribute of query tag will be set to 'modify'.
<?xml version="1.0" encoding="UTF-8"?>
<envelope>
<header>
<actor>test</actor>
<user>test</user>
<password>test</password>
<version>1.6.1</version>
<timestamp>20030423170000</timestamp>
<distributor>5</distributor>
</header>
<query type="book" product="hotel">
<search number="1238"/>
<synchronous value="false"/>
<nationality>IT</nationality>
<checkin date="2003-09-05"/>
<checkout date="2003-09-13"/>
<city code="vce"/>
<availonly value="true" />
<hotel code="2860" agreement="LCL.3186"/>
<reference code="BOOK2005 000001"/>
<responses>
<to url="http://www.yoursite.com/yourprogram.cgi"/>
<to url="mailto://your.address@yoursite.com"/>
</responses>
<details>
<room type="dbl" extrabed="true" cot="true">
<pax leader="true" title="MR" name="GIOVANNI" surname="ROSSI"/>
<pax title="MS" initial="M" surname="ROSSI"/>
<pax title="MR" initial="G" surname="ROSSI" age="5"/>
</room>
</details>
<remarks>
<remark code="RH"/>
<remark code="NSR"/>
<remark code="PFR" text="25EUR"/>
</remarks>
</query>
</envelope>
Query
The query tag has its type attrubute set to "book".
Fields description:
- distributor
- Optional.It can be added in the header; it contains the id of the distributor to use
- search number
- identifies the availability response you are referring to. If you used the evaluate method, in the book request you have to communicate the search number obtained with the evaluate response, not the one retrieved with the initial search.
- availonly
- This tag asks the system not to ever come back with a response in pending status. Sometimes in the meantime between availabilty search and booking a room may not be available anymore, because somebody else has booked it. This is what the availonly flag in the booking request is for. If the system notices that availability for that room has gone, or a number of other issues which would lead to a pending booking, rejects the booking instead.
- hotel
- Reports the hotel to book and its tariff code. The code contains the same value which is contained in the attribute code of hotel tag on the availability query answer.The attribute agreement whereas, contains the value which is existing in the id attribute of agreement tag.
- reference
- This is the user reference. It can be up to 20 characters long and allows only characters in range A-Za-z0-9 and it's reported in the code attribute.
WARNING: different bookings have to report different references. The use of a previous reference in a new booking will raise an error.
- synchronous
- This is the request handling mode. If the "value" attribute is set to "false", then the behaviour is the same of the one previous to version 1.6 of the protocol if set to "true" the behaviour will be synchronous (see "Response" below).
- nationality
- responses
- Reports the way the client system wish to receive the responses. If this tag is omitted, no tracking messages will be sent to the client system. The tag may contains many different destinations for the tracking messages; every destination will receive a tracking message. Please notice that when booking rooms with extrabeds or cots you'll most likely receive an asynchronous tracking response since extrabeds and cots must be approved by the single hotels. Therefore a responses field must be provided when performing such requests in order to tell the system where the tracking response must be provided.
- to
- Describe the destination of a tracking message. The attribute url should contain a valid URL. Supported protocols are:
- http for standard B2B transactions in a web application
- mailto for desktop use, allows a user to receive in her mailbox the tracking messages.
The attribute mode reports the format of the tracking message. There is only one mode: xml (described below)
- room
- same of the availability search except for:
- the extrabed that doesn't require the child age;
- a room tag has to be used for each required room, without merging together rooms of the same type and so omitting the "required" attribute of the tag.
-
pax
- Passenger. The number of passenger in a room has to reflect the requested room type. For every booking has to be defined a leader. The lead passenger is declared setting to y the value of itsleader attribute on true.
The child passenger, if any, has to contain the age attribute set to her age.
The passenger names are formed by the title followed by the initial's letter of the name or by the full name and finally closed by the passenger surname.
The maximum length of the passenger full name (title + surname + name) must be not longer than 50 characters.
Valid value for the title are: MR, MS, MRS and MISS.
A child cannot be lead passenger.
Please note that sending the age tag witout extrabed=true is meaningless and consequently the age attributes will not be considered.
Please also remember that when booking for a room with cots there's no need to add the pax name of the infant as well.
As you can see in the example below, in a double room with an extrabed and a cot you need to put the name of the pax for the extrabed but not for the cot. Total: 4 paxes, 1 infant (in cot), 1 extrabed, two adults.
So you can provide some passengers in full names and some passengers with just the initials as in:
<room type="dbl" extrabed="true" cot="true">
<pax leader="true" title="MR" name="GIOVANNI" surname="ROSSI"/>
<pax title="MS" initial="M" surname="ROSSI"/>
<pax title="MR" initial="G" surname="ROSSI" age="5"/>
</room>
But the preferable way is using always the full names because some hotels could require them as in:
<room type="dbl" extrabed="true" cot="true">
<pax leader="true" title="MR" name="GIOVANNI" surname="ROSSI"/>
<pax title="MS" name="MARIA" surname="ROSSI"/>
<pax title="MR" name="GASTONE" surname="ROSSI" age="5"/>
</room>
- remarks
- If setted, contains a list of coded remarks.
- remark
- Coded remark. The code field contains the remark code, the text field, if used, contains the free text of the remark.
The possible values for code are:
- HM - Honey Mooners
- RA - Adjoining Rooms
- RC - Communicating Rooms
- RH - Highest floor room
- RL - Lower floor room
- EA - Early Check in [fill the attribute text for hour details]
- LA - Late Arrival [fill the attribute text for hour details]
- BK - King size bed
- BQ - Queen size bed
- DSU - Double bed for sole use
- NSR - No smoking room
- RAC - Air conditioned
- PCH - Champagne bottle [fill the attribute text for the price]
- PFR - Fruit basket [fill the attribute text for the price]
- PW - Wine bottle [fill the attribute text for the price]
Response
The response message, in case the default asynchronous mode has been chosen, is used only as a feedback from the server system to the client system. Contains a shorter summary of the booking:
<?xml version="1.0" encoding="UTF-8"?>
<envelope>
<header>
<version>1.6.1</version>
<timestamp>20030423170003</timestamp>
</header>
<response type="book">
<reference code="BOOK2005 000001"/>
<responses>
<to url="http://www.yoursite.com/yourprogram.cgi"/>
<to url="mailto://your.address@yoursite.com"/>
</responses>
<booking name="2014-1231"/>
</response>
</envelope>
The meaning of the tag is the same one which is used in the query message with the only difference of booking name
- Booking Name
- Contains the booking name in our system
In case synchronous mode has been set for messages handling, the returned response would have been of the same format than a booking details request, see "Booking tracking" chapter.