Create or update inventory restrictions¶

Use the OTA_HotelAvailNotif endpoint to update the following elements in the Booking.com system:

The number of rooms available per room type and date combination.
Restrictions per room type, rate and date combination.

Difference between OTA_HotelAvailNotif endpoint v1.0 and v1.1¶

The OTA_HotelAvailNotif endpoint has two versions currently. When migrating to the v1.1 OTA_HotelAvailNotif endpoint, you can view whether a room type is closed. For more information, see RestrictionStatus.

For an update on the changes, see the migration guide.

Header parameter¶

Header	Description	Type	Required/ Optional	Notes
`Accept-Version`	Specify the version number to get the API functionality specific to that version.	string	optional	Supports the following values: - 1.1: New version. - 1.0: Previous version.

Sample header¶

POST 'https://supply-xml.booking.com/hotels/xml/OTA_HotelAvailNotif' \
--header 'Accept-Version: 1.1' \
--header 'Authorization: Basic THVjLVNhbXVlbMblhWTdlOCghQ29qaU9pNmxlWSpIWXU9OigvS2meQpQ12puj' \
--header 'Content-Type: application/xml'

Request (RQ) sent inventory and/or restrictions¶

POST https://supply-xml.booking.com/hotels/ota/OTA_HotelAvailNotif

Request — HTTP Message Body Model¶

<?xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRQ xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRQ.xsd" TimeStamp="2023-10-05T14:20:50" Target="Test" Version="1.005">
  <AvailStatusMessages>
    <AvailStatusMessage BookingLimit="25" LocatorID="1">
      <StatusApplicationControl Start="2023-11-05" End="2023-11-17" InvTypeCode="36745603" />
    </AvailStatusMessage>
    <AvailStatusMessage LocatorID="2">
      <StatusApplicationControl Start="2023-11-05" End="2023-11-17" InvTypeCode="36745603" RatePlanCode="1278606" />
      <LengthsOfStay>
        <LengthOfStay Time="2" MinMaxMessageType="SetMinLOS" />
        <LengthOfStay Time="5" MinMaxMessageType="SetMaxLOS" />
      </LengthsOfStay>
      <RestrictionStatus Status="Open" />
    </AvailStatusMessage>
  </AvailStatusMessages>
</OTA_HotelAvailNotifRQ>

The above example will do the following:

Sets the rooms to sell for room 36745603 to 25 from the 5th of November to and including the 17th of November 2023.
Sets the minimum stay through for room 36745603 and rate 1278606 to 2 nights from the 5th of November to and including the 17th of November 2023.
Set Maximum Stay Through for room 36745603 and rate 1278606 to 5 nights from the 5th of November to and including the 17th of November 2023.

Mandatory elements:¶

OTA_HotelAvailNotifRQ¶

All the below XML is fixed and mandatory, except:

timestamp: Contains the current time and date.

target: Specifies either Production or, Test(used for test properties).

<xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRQ
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.opentravel.org/OTA/2003/05"
  xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRQ.xsd"
  TimeStamp="2023-05-01T06:39:09"
  Target="Test"
  Version="1.005">

AvailStatusMessages¶

The AvailStatusMessages element is mandatory for the OTA_HotelAvailNotif request.

<AvailStatusMessages>
  ...
</AvailStatusMessages>

AvailStatusMessage¶

BookingLimit (optional): Specifies the number of available rooms to sell for a property.

Make sure to omit the Bookinglimit attribute when updating restrictions in the same AvailStatusMessage block, because a RatePlanCode attribute is mandatory in that case and BookingLimit is updated on room level, not rate level.

You can specify a maximum of 254 rooms to sell. Setting a value greater than 255 implies that there are unlimited rooms available, which means that there is no limit to the number of rooms that can be sold until the room type, rate and date combination is closed with a restriction or until the rooms to sell are decreased again. Setting the value of BookingLimit to 256 or higher, results in 254 rooms to sell in the Booking.com system.

LocatorID (required): Contains a unique ID (used as RecordID in OTA_HotelAvailNotifRS)

<AvailStatusMessage BookingLimit="25" LocatorID="1">

StatusApplicationControl¶

Start / End (required): Specifies the period (end date is inclusive). Please note, you can update for periods in the future and up to two day in the past, in the Central European Time (CET) timezone.

RatePlanCode: Contains the Booking.com rate category ID. Not required when specifying Bookinglimit in AvailStatusMessage, as the availability is updated on room level.

InvTypeCode (required): Contains the Booking.com room ID.

<StatusApplicationControl Start="2023-11-05" End="2023-11-17" InvTypeCode="36745603" RatePlanCode="1278606" />

Optional elements¶

LengthsOfStay¶

Is mandatory when specifying element LengthOfStay.

ArrivalDateBased can be set to 0 or 1. If set to 1, then the restriction set has an effect only on the arrival day of a booking. Whereas, setting it to 0 may affect a search for availability or reservation on all the dates that the query covers. The ArrivalDateBased attribute is optional and the default value is 0.

<LengthsOfStay ArrivalDateBased="0">
  <LengthOfStay ... />
</LengthsOfStay>

LengthOfStay¶

The minimum or maximum stay for the given room for the given date for the given rate category. If a booking takes place on this day a minimum or maximum stay (for the whole booking or arrival based, depending on ArrivalDateBased="0" or ArrivalDateBased="1") of this amount of days is required. Each day in a stay has a room and rate category ID associated with it. Each set of consecutive days with the same rate category ID in a stay, must comply with the minimum or maximum stay setting.

<LengthOfStay Time="2" MinMaxMessageType="SetMinLOS"/>
<LengthOfStay Time="5" MinMaxMessageType="SetMaxLOS"/>

Removing minimum and maximum length-of-stays¶

To remove an existing length-of-stay restriction you must send a request to update the minimumstay or maximumstay value to 0. You can encounter the following scenarios:

Update only Time="0" for MinMaxMessageType="SetMinLOS" if you want to remove the minimum stay restriction.
Update only Time="0" for MinMaxMessageType="SetMaxLOS" if you want to remove the maximum stay restriction.
Update both if you want to remove minimum and maximum stay restrictions.

To reinstate restrictions, you must send another request with the value representing the desired amount of days for either or both length-of-stay restrictions.

RestrictionStatus¶

Mandatory attributes:

Status=""

Using the Status attribute, you can:

[Only available in version 1.1] Close the specified room type. The room type will not be available for booking for the specified period, irrespective of whether the room has an open room and rate combination. To close the room type you must not include the RatePlanCode in the request.
Close the availability for the specified room type and rate combination by specifying the RatePlanCode in the request.

If set to Close (or Open), the room is closed (or opened) for the specified date. When a room is closed, all other information such as Bookinglimit, prices, and so on is preserved.

Optional attributes:

Restriction=""

The restriction attribute may contain Departure or Arrival.

Where a Close for Restriction Arrival doesn't allow a reservation to be made when guests want to arrive at the selected date. When the restriction is set to Open for a certain date, guests are free to make a reservation with arrival on this date whereas a Close will restrict guests to book rooms with this arrival date.

A Close for Restriction Departure doesn't allow a reservation to be made when visitors want to depart on the selected date. When the restriction is set to Open for a certain date, guests are free to make a reservation with departure on this date whereas a Close will restrict guests to book rooms with this departure date.

MinAdvancedBookingOffset=""
MaxAdvancedBookingOffset=""

MinAdvancedBookingOffset means the minimum time before the checkin date guests will be allowed to make a booking. The maximum supported value is 360D.

MaxAdvancedBookingOffset means the maximum time before the checkin date the guests will be allowed to make a booking. The maximum supported value is 360D.

Both have the same format. The search date is counted as one of the days in the restriction length.

Examples:

MinAdvancedBookingOffset="4D" means the room must be booked at least 4 days in advance.
MinAdvancedBookingOffset="4H" means the room must be booked at least 4 hours in advance.
MinAdvancedBookingOffset="4D4H" means the room must be booked at least 4 days and 4 hours in advance.

To set restrictions using MinAdvanceBookingOffset or MaxAdvanceBookingOffset you must pass a RatePlanCode. If a RatePlanCode is not passed, the API returns an error.

<StatusApplicationControl Start="2023-11-05" End="2023-11-17" InvTypeCode="36745603" RatePlanCode="1278606" />
  <RestrictionStatus Restriction="Departure" Status="Open"/>
</AvailStatusMessage>

Response¶

OTA_HotelAvailNotifRS¶

All the below code is fixed, except:

TimeStamp: Contains the current time.

Target: Set to same value as in the corresponding OTA_HotelAvailNotifRQ.

<?xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRS.xsd" TimeStamp="2023-10-11T15:30:04-00:00" Target="Test" Version="1.004">
  <Success />
</OTA_HotelAvailNotifRS>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXX] -->

Success¶

Success element is optional, depending on whether the request contained mistakes.

<?xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRS.xsd" TimeStamp="2023-10-05T12:20:50-00:00" Target="Test" Version="1.004">
  <Success />
</OTA_HotelAvailNotifRS>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXX] -->

Warnings¶

Warnings can be combined with success messages if the request was still processed.

Type: OTA error code (see OTA codetable).

Code: OTA EWT code (see OTA codetable).

RecordID: same as LocatorID in OTA_HotelAvailNotifRQ.

Status: NotProcessed (error) / Complete (only warning).

ShortText (may be empty): warning message.

<?xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRS.xsd" TimeStamp="2023-10-11T15:32:03-00:00" Target="Test" Version="1.004">
  <Success />
  <Warnings>
    <Warning Type="1" Code="367" Status="Complete" ShortText="Rooms to Sell were set below the Minimum Contracted rooms for these dates: 2023-11-15, 2023-11-07, 2023-11-12, 2023-11-13, 2023-11-08, 2023-11-09, 2023-11-17, 2023-11-14, 2023-11-06, 2023-11-11, 2023-11-16, 2023-11-05, 2023-11-10. The values have been amended to the Minimum Contracted Rooms."/>
  </Warnings>
</OTA_HotelAvailNotifRS>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] -->

Errors¶

Errors are optional and only used alone, without success/warnings.

Code: OTA EWT code (see OTA codetable).

Type: OTA error code (see OTA codetable).

RecordID: same as LocatorID in OTA_HotelAvailNotifRQ.

Status: NotProcessed.

ShortText (may be empty): error message.

<OTA_HotelAvailNotifRS xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelAvailNotifRS.xsd" TimeStamp="2023-10-12T07:36:16-00:00" Target="Test" Version="1.004">
  <Errors>
    <Error Type="1" Code="367" Status="NotProcessed" ShortText="xml parse error"/>
  </Errors>
</OTA_HotelAvailNotifRS>

The Booking.com responses will contain a RUID string, which is an encoded string used by the Booking.com staff to trace back any updates made before. Whenever the Connectivity Partner wishes the XML-Team to look at any logfiles for debugging or the like; the RUID string needs to be provided. This will enable the Booking.com technical staff to provide Connectivity Partners with support.

RUID¶

<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] -->

Is this page helpful? Yes | No