| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
1. GENERAL
1.1 - Linespacing
The entire message should be contained on one single line only:
| Expand |
|---|
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1"><wsse:UsernameToken><wsse:Username>USERNAME</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SECRET</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><OTA_ReadRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="1.0" EchoToken="64265f9f-5b82-409e-8d8d-058e04b6df40" TimeStamp="2018-06-20T16:32:52+08:00"><POS><Source><RequestorID Type="22" ID="PMS1"/></Source></POS><ReadRequests><HotelReadRequest HotelCode="ABC"><SelectionCriteria SelectionType="Undelivered" ResStatus="Book"/></HotelReadRequest></ReadRequests></OTA_ReadRQ></soap:Body></soap:Envelope> |
1.2 - SOAP header
All the
| Status | ||||
|---|---|---|---|---|
|
1.3 - WSSE namespace
As the soap:Header / Security element conveys authentication information, it should have its namespace declared as
| Status | ||||
|---|---|---|---|---|
|
1.4 - EchoToken
| Status | ||||
|---|---|---|---|---|
|
1.5 - TimeStamp
DateTime format requested: yyyy-MM-dd'T'HH:mm:ss+XX:XX, no milliseconds. If no timezone is declared, we assume the PMS is using UTC as this is the default timezone. If a timezone is declared, the time value should reflect the actual local time. The same goes for @CreateDateTime / @LastModifyDateTime.
UTC: “2018-06-20T08:32:52” valueequals GMT+8: “2018-06-20T16:32:52+08:00”
1.6 - Day Indicators
if using, make sure it doesn’t restrict updates from being applied. For instance, if the message contains a date range consisting of 2018-12-04 (Tuesday) and 2018-12-05 (Wednesday),Tue="0" and Weds="0" will block the update.
...
2. ARI UPDATES
2.1 - Data Bundling
Rate, Availability or Restriction updates must be
| Status | ||||
|---|---|---|---|---|
|
...
This is NOT expected:
...
2.2 - Delta Updates
All the requests (Availability, Restrictions & Rates) must only contain data relevant to the action being performed in your PMS. In other words, we require the messages to be as small as possible, meaning that only the modifications should be sent. No unchanged dates should be included in these request messages. For instance, if in a certification scenario we ask you to update ‘Availability’ to ‘4’ for Double Room (DBL) - Best Available Rate (BAR) for the 8th of November 2018, we expect to receive one single request containing only one message exclusively consisting of Availability data and nothing else:
...
This is NOT expected:
...
2.3 - Availability
Room Level: in the case your PMS operates on Room (Type) Level availability, do NOT include @RatePlanCode to your availability messages. Therefore, it is advisable to push availability updates separately from restriction updates to avoid sending through the same information (@BookingLimit) in case there’s multiple rate plans linked to the same room type. This means we do not need to read and validate it multiple times as well.
...
Availability and Restrictions bundled together into one message:
...
2.4 - Min / Max LOS Restrictions
If certifying for both, make sure to bundle Minimum and Maximum LOS where applicable:
...
The above isn’t available for RestrictionStatus element as there can only be one RestrictionStatus element per AvailStatusMessage.
2.5 - Stop Sell / CTA / CTD
Note that StopSell, CTA and CTD are completely independent from each other. A room can be open <RestrictionStatus Status="Open"/> while CTA (or CTD) being applied <RestrictionStatus Restriction="Arrival" (Restriction="Departure") Status="Close"/> at the same time, and vice versa. In other words - StopSell, CTA and CTD can be received separately so their status should be assumed as separate - for instance, a message which sets StopSell will not change the states of closed to arrival and departure.
Similarly, when removing CTA or CTD, @Restriction attribute has to be used as well:
<RestrictionStatus Restriction="Arrival" Status="Open"/>
<RestrictionStatus Restriction="Departure" Status="Open"/>
Restriction Type | How it will be sent |
Room is stop sold | <RestrictionStatus Status="Close"/> |
Room is opened for sale | <RestrictionStatus Status="Open"/> |
Room is set as closed to arrival | <RestrictionStatus Status="Close" Restriction="Arrival"/> |
Room is set as open to arrival | <RestrictionStatus Status="Open" Restriction="Arrival"/> |
Room is set as closed to departure | <RestrictionStatus Status="Close" Restriction="Departure"/> |
Room is set as open to departure | <RestrictionStatus Status="Open" Restriction="Departure"/> |
2.6 - Rates
Rate is a positive decimal value - a rate of 156 should be sent through as 156.00:
...
<Rate CurrencyCode="AUD" Start="2019-01-01" End="2019-01-14">
...
3. RESERVATION SERVICE
3.1 - Reservation polling interval
Ensure to pull reservations every 2-5 minutes. In other words, reservations / modifications / cancellations should never be requested more often than every 2 minutes and less often that every 5 minutes.
3.2 - Steps involved
Make sure to cover all the steps involved in the Reservation API for each reservation / modification / cancellation (if applicable):
...
Make sure to confirm the reservation delivery and send us back the affected availability as fast as possible, preferably under 1 minute.
3.3 - Availability pass back request
This is a delta update meaning that only the affected availability should be sent through. Note, The Channel Manager does NOT top up the availability after a modification / cancellation delivery. As a result, ensure the following:
...
Expected - availability top up back to “3” for all dates affected by this cancellation:
...
3.4 - OTA_NotifReportRQ
Confirmation request specification:
...
If ResStatus is “Modify” or “Cancel” - @
| Status | ||||
|---|---|---|---|---|
|
...
3.5 - Error handling
If a reservation cannot take place (for instance, your PMS doesn’t support overbookings and there’s no availability), ensure to be as specific as possible in your error response. Hoteliers receive
| Status | ||||
|---|---|---|---|---|
|
...