# Create or update inventory restrictions

Use the `OTA_HotelAvailNotif` endpoint to:

- Set the number of rooms available (`BookingLimit`) for a room type and date combination
- [Close a room type on a specified date](#closing-room-type-vs-room-and-rate-combination). Even if roomrates are open, the room type is not available for booking
- Set restrictions by specifying room type, rate plan, and date


## Usage recommendations

1. **Specify availability in advance**: Provide availability for at least 12 months ahead.
2. **Use Delta Updates Only**: Send only changes using the [roomRateAvailability API](/connectivity/docs/b_xml-roomrateavailability), not full refreshes.
3. **Single Hotel Per Request**: All updates must belong to one hotel only.
4. **Monthly Batching**: Break down updates by month: one month per request.
5. **Room-Rate Grouping**: Multiple room-rates can be grouped in the same request for the same hotel and month.


## Endpoint


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

## Request

### Headers

| Header | Description | Type | Required | Notes |
|  --- | --- | --- | --- | --- |
| `Accept-Version` | Specify the version number to get the API functionality specific to that version. | string | Required | Supports the following values:- 1.1: Current version (default) |
| `Content-Type` | Request content type | string | Required | Must be `application/xml` |


### Request body

| Element | Attribute | Description | Type | Required | Notes |
|  --- | --- | --- | --- | --- | --- |
| `OTA_HotelAvailNotifRQ` |  | Root element. | object | Required | - |
| **>** `AvailStatusMessages` |  | Root element for availability updates. | object | Required | - |
| **>>** `AvailStatusMessage` |  | Container for status messages. | object | Required | - |
|  | `BookingLimit` | Specifies the number of rooms of this type that Booking.com can sell. The number of available rooms applies across all rates including prices set using other rates for the same room type. | integer | Optional | Maximum value: `254`**NOTE:** Use `255` to indicate unlimited rooms. Values greater than `255` are automatically reset to `254`. |
| **>>>** `StatusApplicationControl` |  | Defines the scope of the update. | object | Required | - |
|  | `Start` | Start date of period. Supports dates from 1 day in the past (follows Central European Time (CET) timezone) and up to 5 years in future | date | Required | Format: `yyyy-MM-dd` |
|  | `End` | End date of period (inclusive). Supports dates from 1 day in the past (follows Central European Time (CET) timezone) and up to 5 years in future | date | Required | Format: `yyyy-MM-dd` |
|  | `InvTypeCode` | Booking.com room ID. | string | Required | - |
|  | `RatePlanCode` | Booking.com rate plan ID. | string | Conditional | Required when updating restrictions.Not required when specifying `BookingLimit` in `AvailStatusMessage`, as the availability is updated on room level. |
| **>>>** `LengthsOfStay` |  | Root element for length of stay restrictions. | object | Optional | - |
|  | `ArrivalDateBased` | Restriction applies to arrival day. | boolean | Optional | Default: `0`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.To set both length-of-stay restriction (`ArrivalDateBased="0"`) and length-of-stay restriction on the arrival day (`ArrivalDateBased="1"`), you must send those restrictions in separate `AvailStatusMessage` blocks. |
| **>>>>** `LengthOfStay` |  | Defines minimum or maximum stay requirements. | object | Optional | - |
|  | `Time` | Number of days for the length of stay restriction. | integer | Optional | Specifies the minimum or maximum number of nights a guest must book.**How it works:**- When `ArrivalDateBased="0"` (default): The restriction applies if the stay **includes** the specified date (stay-through restriction)- When `ArrivalDateBased="1"`: The restriction applies only if the guest **checks in** on the specified date (arrival-based restriction)**NOTE:** Each consecutive set of nights with the same rate plan must comply with the restriction. `0` means no restriction. |
|  | `MinMaxMessageType` | Type of length of stay restriction. | string | Optional | Possible values:- `SetMinLOS`: Sets minimum length of stay- `SetMaxLOS`: Sets maximum length of stay |
| **>>>** `RestrictionStatus` |  | Root element for restriction status. | object | Optional | - |
|  | `Status` | Specifies whether all rooms of a room type are closed (not bookable) or only the specified room type and rate combination on the specified date depending on whether the `RatePlanCode` is provided. | string | Optional | Values: `Open` or `Close`.**Closing behavior depends on whether `RatePlanCode` is included:**- **Without `RatePlanCode`**: Closes the entire room type for all rates. The room type will not be available for booking, even if individual room and rate combinations are open.- **With `RatePlanCode`**: Closes only the specific room type and rate combination.**NOTE:** When a room is closed, all other information such as `BookingLimit`, prices, and restrictions are preserved. See also [Closing room type vs. room and rate combination](#closing-room-type-vs-room-and-rate-combination). |
|  | `MinAdvancedBookingOffset` | The minimum number of days and/or hours that guests must book in advance (before the stay date at 24:00 in the hotel timezone). | string | Optional | Format: `nD` or `nH` or `nDnH`. Maximum: 360DThe search date is counted as one of the dates in the restriction.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. |
|  | `MaxAdvancedBookingOffset` | The Maximum number of days and/or hours that guests must book in advance (before the stay date at 24:00 in the hotel timezone). | string | Optional | Format: `nD` or `nH` or `nDnH`. Maximum: 360DThe search date is counted as one of the dates in the restriction. |


### Request example

The request below specifies 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
* Sets the 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
* Opens the room and rate combination for booking



```xml
<?xml version="1.0" encoding="UTF-8"?>
<OTA_HotelAvailNotifRQ>
  <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>
```

## Response

### Response body

| Element | Attribute | Description | Type | Notes |
|  --- | --- | --- | --- | --- |
| `OTA_HotelAvailNotifRS` |  | Root element. | object | - |
| **>** `Success` |  | Indicates a successful request. | object | Only returned if there are no `Errors` elements. |
| **>** `Warnings` |  | Groups a list of individual warnings. | object | - |
| **>>** `Warning` |  | List details of individual warnings. | object | Warnings can occur even if the response contains `Success`. |
|  | `Code` | Returns an error code for an error. | string | See [Troubleshooting availability error responses](/connectivity/docs/b_xml-availability-troubleshooting) |
|  | `Details` | Contains additional context about where the warning occurred. | string | May include identifiers such as `hotel_id`, `room_id`, `rate_id`, or `date` to help identify the specific data that caused the warning. |
|  | `ShortText` | Warning message. | string | - |
| **>** `Errors` |  | Groups a list of individual errors. | object | - |
| **>>** `Error` |  | List details of individual errors. | object | - |
|  | `Code` | Returns an error code for an error. | string | See [Troubleshooting availability error responses](/connectivity/docs/b_xml-availability-troubleshooting) |
|  | `Details` | Contains additional context about where the error occurred. | string | May include identifiers such as `hotel_id`, `room_id`, `rate_id`, or `date` to help identify the specific data that caused the error. |
|  | `ShortText` | Error message. | string | - |


### Response examples

This section contains examples of successful and unsuccessful responses. For a detailed description of all possible errors and warnings, see [Troubleshooting availability error responses](/connectivity/docs/b_xml-availability-troubleshooting).

#### Success response


```xml
<?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"
                       Version="1.004" TimeStamp="2026-02-12T15:35:01.665872Z">
  <Success />
</OTA_HotelAvailNotifRS>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXX] -->
```

#### Success response with warnings (HTTP 200)

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


```xml
<?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" 
                       Version="1.004" TimeStamp="2026-02-12T15:35:01.665872Z">
  <Success />
  <Warnings>
    <Warning Code="367" 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] -->
```

#### Error response (HTTP 400)

Errors are returned without success/warnings elements.


```xml
<?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"
                       Version="1.004" TimeStamp="2026-02-12T15:35:01.665872Z">
    <Errors>
        <Error Code="RATE_NOT_ACTIVE_FOR_ROOM" ShortText="Rate '123' is not active for room '456'" Details="room_ids: 12345; rate_ids: 45678; dates: 2026-02-12,2026-02-12; hotel_ids: 456789;"/>
    </Errors>
</OTA_HotelAvailNotifRS>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] -->
```

## Additional information

### Setting availability for child rates

While setting up availability using rate IDs that are configured as [child rates](/connectivity/docs/room-type-and-rate-plan-management/managing-rate-plans#create-a-rate-relation), make sure the request doesn't set values for fields that are [configured to inherit from the parent rate plan](/connectivity/docs/room-type-and-rate-plan-management/managing-rate-plans/#parentrate).

For example, if you try to set a value for `min_advance_res` restrictions for a child rate while the child rate is configured to [follow restrictions](/connectivity/docs/room-type-and-rate-plan-management/managing-rate-plans/#followsrestrictions) the API returns an error.

To resolve the error, specify a rate plan ID that is either configured as a parent rate, or a child rate that does not have the following restrictions: `FollowsRestrictions`.

The above constraint does not apply to the [`FollowsClosed` restriction](/connectivity/docs/room-type-and-rate-plan-management/managing-rate-plans/#followsclosed). While creating availability using a child rate ID, you can update the status of the room type to open or close, irrespective of the value set in `FollowsClosed`. However, if an availability is set using a parent rate along with open/close information, then the room type status for the associated child rate is also updated. To reiterate, there is no change to the `FollowsClosed` restriction behaviour.

### Closing room type vs. room and rate combination

You can close availability at the:

- **Room type level**: Useful when removing availability for all rooms of a room type that has multiple rate combinations.
- **Room type and rate combination level**: Useful when removing availability for a room type satisfying a specific rate combination.


Consider the following inventory:

| Room type | Rate | Price | Date period | Rooms to sell |
|  --- | --- | --- | --- | --- |
| Villa | Summer rate | 110 | Jul 15 - Aug 31 | 10 |
| Villa | Peak season rate | 120 | Aug 05 - Aug 20 | 10 |
| Villa | Off season rate | 90 | Nov 01 - Dec 10 | 10 |


#### Closing room type and rate combination

To close the availability of the Villa so that guests don't see availability from Nov 01 - Dec 10, you must close the room type (Villa) and rate combination (Off season rate) by:

1. Setting `InvTypeCode` to the Villa room ID
2. Setting `RatePlanCode` to the Off season rate ID
3. Setting `RestrictionStatus Status="Close"`


#### Closing a room type

To close the availability of a specific room type (Villa) so that guests don't see availability for a specific period, you must close the room type by:

1. Setting `InvTypeCode` to the Villa room ID
2. **Not including** `RatePlanCode` in the request
3. Setting `RestrictionStatus Status="Close"`


Once a room is closed you must open it before creating availability
Before creating availability for a room that is closed, you must use the `OTA_HotelAvailNotif` endpoint to open the room. Otherwise, the request to create availability completes successfully, but guests will not be able to see the availability as the room is still closed.