Create or update inventory, rates and restrictions

Use the availability endpoint to:

• Set adult prices by specifying room type, rate plan and date.
• Set prices for children by specifying room type, rate plan and date. Check flexible children rates.
• Set number of rooms to sell (roomstosell) for a room type. Note that the number of rooms applies to all rates.
• Close a room type on a specified date. Even if roomrates are open, the room type is not available for booking.
• Set restrictions by specifying room type, rate plan and date.

Booking.com supports different pricing models. Ensure you're using the correct pricing approach for your property For more information on pricing models, see Pricing Models.

Usage recommendations

1. Specify availability in advance: You should specify the availability of your connected properties at least 12 months in advance.

2. Use Delta Updates Only

   • Utilize the roomRateAvailability API to compare system states
   • Send only changes (deltas), not full system refreshes

3. Single Hotel Per Request

   • All updates in a request must belong to one hotel
   • Do not mix multiple hotels in the same request

4. Monthly Batching

   • Break down updates by month
   • Each request should cover a single month period

5. Room-Rate Grouping

   • Multiple room-rates can be grouped together in the same request
   • Must be for the same hotel and same month period

Endpoint

POST https://supply-xml.booking.com/hotels/xml/availability

Request

Headers

Request body

Request example

The request below specifies the following booking conditions for room type 1000202, with rate 12345, on 28 August, 2023:

• The property has 1 room of this type available for sale (roomstosell).
• The room is available to book on this date, for this rate, only if the stay is at least 2 nights, and at most 14 nights (minimumstay, maximumstay).
• The room costs 135 (in the property's local currency) per night for one person, or 150 per night for the maximum number of persons.
• The room is not available to book for this rate if the planned check-out date is 28 August (closedondeparture).

<request>
  <room id="1000202">
    <date value='2023-08-28'>
      <roomstosell>1</roomstosell>
    </date>
  </room>
  <room id="1000202">
    <date value="2023-08-28">
      <currencycode>EUR</currencycode>
      <rate id="12345"/>
      <price>150.00</price>
      <price1>135.00</price1>
      <closed>0</closed>
      <minimumstay>2</minimumstay>
      <maximumstay>14</maximumstay>
      <closedonarrival>0</closedonarrival>
      <closedondeparture>1</closedondeparture>
    </date>
  </room>
</request>

Response

Response body

Response examples

This section contains examples of successful and unsuccessful responses. For a detailed description of all possible errors and warnings, see Troubleshooting B.XML availability error responses.

Success response

<ok></ok>
<!-- RUID: [XXXXXXXXXXXXXXXXXXXXXXX==] -->

Error response (HTTP 400)

<availability>
  <errors>
    <error code="NOT_A_VALID_DATE">
      <message>Dates should be in YYYY-MM-DD format, not before '2023-01-08',
        and not be past '2033-12-31'. The data should also be valid.</message>
      <details>
        <dates>2022-12-12</dates>
      </details>
    </error>
    <error code="RATE_NOT_ACTIVE_FOR_ROOM">
      <message>Rate '1234' is not active for room '4567'</message>
      <details>
        <room_ids>4567</room_ids>
        <hotel_ids>789</hotel_ids>
        <dates>2023-05-02</dates>
        <rate_ids>1234</rate_ids>
      </details>
    </error>
  </errors>
</availability>
<!-- RUID: [UmFuZG9tSVetc] -->

Partial success response (HTTP 200)

A response with status code HTTP/1.1 200 OK may still have errors in the body, meaning that some updates were applied successfully while others failed:

<availability>
  <errors>
    <error code="NOT_A_VALID_DATE">
      <message>Dates should be in YYYY-MM-DD format, not before '2023-01-08',
        and not be past '2033-12-31'. The data should also be valid.</message>
      <details>
        <dates>2022-12-12</dates>
      </details>
    </error>
  </errors>
</availability>
<!-- RUID: [UmFuZG9tSVetc] -->

Success response with warnings (HTTP 200)

<availability>
  <warnings>
    <warning code="WARN_TOO_LARGE_NUMBER_ROOMS_TO_SELL">
      <details>
        <hotel_ids>1234</hotel_ids>
        <room_ids>12345</room_ids>
      </details>
      <message>Changed too large number of Rooms To Sell to 254 for: 2023-10-25</message>
    </warning>
  </warnings>
</availability>
<!-- RUID: [UmFuZG9tSVetc] -->

Warnings will not prevent a request from processing. They merely point out unexpected or unadvisable behaviour. We recommend that you keep the number of warnings to zero.

Additional information

Price limits and validation

Setting availability for child rates

While setting up availability using rate IDs that are configured as child rates, make sure the request doesn't set values for fields that are configured to inherit from the parent rate plan.

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 or set price when FollowsPrice is set, 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: FollowsPrice, or FollowsRestrictions.

The above constraint does not apply to the FollowsClosed restriction. 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:

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 providing the following parameters: room, date, rate, closed.

Closing a room type

To close the availability of a specific room type, say Villa, so that guests don't see availability for a specific period, you must close the room type (Villa) by providing the following parameters: room, date, closed.