Migrating to new versions

At Booking.com, we want to continuously improve the Connectivity Partner experience. This means we try to build better products and deprecate the older versions. When Booking.com plans to deprecate a feature or a product, you can no longer use it after the communicated date of deprecation. To help facilitate the potential changes you must make, the migration guide tables on this page aim to help you understand what is deprecated and what its (improved) alternative is.

Changes to the Derived Prices endpoint

The following improvements are rolled out to the derivedprices endpoint v1.1.

The changes outlined in this section are applicable only when using the /hotels/xml/derivedprices endpoint with a special header parameter. The following section covers only the changes available in v1.1. For a detailed explanation of the /hotels/xml/derivedprices endpoint, see Create or update derived pricing rates.

When you migrate to v1.1 of the derivedprices endpoint, you can see the following change in the API behaviour:

When migrating to the v1.1 /hotels/xml/derivedprices endpoint, you get:

• Improved error handling and error description.
• Improved latency.

Header parameter

Sample header

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

New error codes on v1.1

The following table summarises the new error codes for the derivedprices endpoint.

HTTP error code behaviour on v1.1

With the v1.1 of the derivedprices endpoint, we have standardised the treatment of the HTTP error codes. The following table captures all the common conditions and the HTTP error codes that was previously returned by v1.0 compared to the v1.1 endpoint.

Migrating to a new promotion ID prefix

The Promotions API, as of March 27, 2024, returns the new prefix TB instead of the previously used VR prefix whenever you create or update a promotion. We plan to automatically change the ID of promotions prefixed with VR to a new ID using the getpromotions endpoint, effective from January 31st, 2025. After the change, those promotions will get a new ID prefixed with TB, followed by a unique string.

What we expect from Connectivity Partners

To ensure all your promotions use the new prefix, complete the following actions before January 31st, 2025:

1. Retrieve all existing promotions for a property using the getpromotions endpoint and note down the promotions with prefix VR. Make sure to specify the hotel_id and active parameters.

Request example

The following example shows how to retrieve all active promotions including those with prefix VR of an existing property using the POST /hotels/xml/getpromotions endpoint.

<request>
    <hotel_id>12312</hotel_id>
    <active>1</active>
 </request>

2. For each promotion still using the VR prefix, generate a new promotion ID with the TB prefix. Use the POST /promotions endpoint and send only the existing promotion ID in the request body. This will return a new promotion ID with the TB prefix.

Request example

The following example shows how to update the ID of an existing promotion with a VR prefix to get a new promotion ID with a TB prefix using the POST /hotels/xml/promotions endpoint.

<request>
    <hotel_id>12312</hotel_id>
     <promotion 
         id="VR123456789">
     </promotion>
 </request>

Sample response

<promotions>
    <id>TB437287097257498474</id>
</promotions>
<!-- RUID: [...] -->

Changes to the Reservations API response

We have rolled out changes to the way the Reservations API calculates and displays the breakdown of the total price for each booking. You can get the changed Reservations API response by enabling the feature: Payments Clarity Package v2 (payment_clarity_package_v2).

For more information, see the table below:

Changes to the Market insights API error handling

We are changing how we return error code responses in the Market insights API. To follow the new Online Travel Agency(OTA) standards in processing error codes, the Market Insights API will return OTA error codes in place of error strings.

Instead of a string value in the [Old] Error Code column, the API returns a numeric value as specified in the [New] OTA Error Code column. The API returns the old message values in the Description field.

For more information on the Market insights API, see Analysing Booking.com guests' demand data.

Changes to the LOS pricing endpoint

The following improvements are rolled out to the /hotels/csv/los_pricing endpoint v1.1. We plan to deprecate v1.0 of the hotels/csv/los_pricing endpoint. For the deprecation and sunset timeline, see the Deprecation and sunsetting topic.

The changes outlined in this section are applicable only when using the hotels/csv/los_pricing endpoint with a special header parameter. The following section covers only the changes available in v1.1. For a detailed explanation of the hotels/csv/los_pricing endpoint, see [Create or update LOS pricing rates.] (/connectivity/docs/csv-los_pricing.md)

The following are the changes implemented in the v1.1 hotels/csv/los_pricing endpoint:

• The occupancy value cannot exceed the value set in the MaxAdultOccupancy. Specifying the maximum occupancy value (MaxOccupancy) in v 1.0 doesn't return a warning. Whereas, in v 1.1 the endpoint returns a warning. Make sure to specify a value not exceeding the MaxAdultOccupancy value.
• If the specified price per night exceeds the maximum price (€50000 or equivalent), then the API rejects the price update request. This differs from the previous behaviour: where the API sets the price to 0 and automatically closes the room.
• While setting up pricing for an inventory 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 price for a child rate while the child rate is configured to follow price, the API returns a partial success response with an error message. 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 FollowsPrice restriction set.
• Accepts past date updates up to 1 day in the past (follows Central European Time (CET) timezone). Updates more than 1 day in the past returns a NOT_A_VALID_DATE error.
• Some existing error messages were improved for better clarity. For a list of all the error message changes see changes to existing error messages.

Header parameter

Sample header

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

HTTP error code behaviour on v1.1 los_pricing

With the v1.1 of the los_pricing endpoint, we have standardised the treatment of the HTTP error codes. The following table captures all the common conditions and the HTTP error codes that the v1.1 endpoint returns.

Changes to existing behaviour

When you migrate to v1.1 of the los_pricing endpoint, you can see the following change in the API behaviour:

Changes to the OTA_HotelRateAmountNotif endpoint

The following improvements are rolled out to the OTA_HotelRateAmountNotif endpoint. We plan to deprecate v1.0 of the OTA_HotelRateAmountNotif endpoint by 31 January 2024 11:00 am CEST with a planned sunset date of February 14, 2024. For more information on the deprecation timeline, see the Deprecation and sunsetting topic.

The changes outlined in this section are applicable only when using the OTA_HotelRateAmountNotif endpoint with a special header parameter. The following section covers only the changes available in v1.1. For a detailed explanation of the OTA_HotelRateAmountNotif endpoint, see Create or update rates.

When migrating to the v1.1 OTA_HotelRateAmountNotif endpoint, you get:

• Improved API behaviour.
• Improved error handling and error description.
• Improved latency.

Header parameter

Sample header

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

Sample request

The following example is to set price per rate/room/date for a property using Occupancy based pricing type. Note: If only a few weekdays are marked as true then the API marks the other days as false. However, if some weekdays are marked as false, then the API considers this as sending none as true and therefore marks all weekdays as true.

<OTA_HotelRateAmountNotifRQ>
   <RateAmountMessages>
      <RateAmountMessage LocatorID="1">
         <StatusApplicationControl Sat="true" Sun="true" Start="2023-11-19" End="2023-12-20" RatePlanCode="25278032" InvTypeCode="801185512" />
         <Rates>
            <Rate MinLOS="1" MaxLOS="1" RateTimeUnit="Day" UnitMultiplier="1" MinGuestApplicable="1" MaxGuestApplicable="4">
               <BaseByGuestAmts>
                  <BaseByGuestAmt AmountBeforeTax="3800" DecimalPlaces="2" NumberOfGuests="4" CurrencyCode="EUR" />
               </BaseByGuestAmts>
               <AdditionalGuestAmounts>
                  <AdditionalGuestAmount AgeBucketID="1" AdditionalGuestNumber="1" Amount="0.01" DecimalPlaces="0" AgeQualifyingCode="8" />
                  <AdditionalGuestAmount MinAge="2" MaxAge="5" AdditionalGuestNumber="1" Percent="5" DecimalPlaces="0" AgeQualifyingCode="8" />
               </AdditionalGuestAmounts>
            </Rate>
         </Rates>
      </RateAmountMessage>
   </RateAmountMessages>
</OTA_HotelRateAmountNotifRQ>

Sample response

<OTA_HotelRateAmountNotifRS 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_HotelRateAmountNotifRS.xsd" TimeStamp="2023-10-12T11:34:06-00:00" Target="Production" Version="1.006"> 
    <Success /> 
</OTA_HotelRateAmountNotifRS>

Sample error response

<OTA_HotelRateAmountNotifRS> 
<Errors>
   <Error Code="RATE_NOT_ACTIVE_FOR_ROOM" ShortText="Rate '18858134' is not active for room '28301'" Details="rate_ids: 18134; dates: 2024-04-11,2024-04-12; hotel_ids: 2783; room_ids: 28301;"/>
</Errors>
</OTA_HotelRateAmountNotifRS>

Changes to the OTA_HotelRateAmountNotif behaviour

The following are the changes implemented in the v1.1 OTA_HotelRateAmountNotif endpoint:

• If the specified price per night exceeds the maximum price (€50000 or equivalent), then the API rejects the price update request. This differs from the previous behaviour: where the API sets the price to 0 and automatically closes the room.
• While setting up price per rate, room and date combination 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 price for a child rate while the child rate is configured to follow price, the API returns a partial success response with an error message. 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 FollowsPrice restriction set.
• When setting decimal prices, you must use the period decimal separator and not the comma separator. For example, 75.50 is a valid price definition whereas 75,50 returns an HTTP 400 status error.
• Accepts past date updates up to 1 day in the past (follows Central European Time (CET) timezone). Updates more than 1 day in the past returns a NOT_A_VALID_DATE error.
• It is recommended to use the NumberOfGuests attribute instead of the MinGuestApplicable and MaxGuestApplicable attributes.

Header parameter

Sample header

POST 'https://supply-xml.booking.com/ota/OTA_HotelRateAmountNotif' \
--header 'Accept-Version: 1.1' \
--header 'Authorization: Basic THVjLVNhbXVlbMblmRAdlOCghQ29qaU9pNmxlWSpIWXU9OigvS2meQpQ12puj' \
--header 'Content-Type: application/xml'

HTTP error code behaviour on v1.1 OTA_HotelRateAmountNotif

With the v1.1 of the OTA_HotelRateAmountNotif endpoint, we have standardised the treatment of the HTTP error codes. The following table captures all the common conditions and the HTTP error codes that the v1.1 endpoint returns.

New warnings on v1.1

The following table summarises the new warnings for the OTA_HotelRateAmountNotif endpoint.

New error codes on v1.1

The following table summarises the new error codes for the OTA_HotelRateAmountNotif endpoint.

Changes to the roomrateavailability endpoint

The following updates are available to the roomrateavailability endpoint with the version 1.1.

Difference between roomrateavailability endpoint v1.0 and v1.1

You can use the roomrateavailability endpoint in two versions. In addition to the functionality available in v1.0, when migrating to the v1.1 roomrateavailability endpoint, you can view whether a room type is closed. For more information on the existing functionality, see Retrieve inventory and rate details.

Header parameter

Sample header

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

Response parameters

Changes to the OTA_HotelAvailNotif endpoint

The following improvements are rolled out to the OTA_HotelAvailNotif endpoint.

The changes outlined in this section are applicable only when using the OTA_HotelAvailNotif endpoint with a special header parameter. The following section covers only the changes available in v1.1. For a detailed explanation of the OTA_HotelAvailNotif endpoint, see Create or update inventory, restrictions.

When migrating to the v1.1 OTA_HotelAvailNotif endpoint, you get:

• To close a room type on a specified date. Even if roomrates are open, the room type is not available for booking.
• Set past date updates up to 1 day in the past (follows Central European Time (CET) timezone). Updates more than 1 day in the past, return a NOT_A_VALID_DATE error.
• Improved API behaviour.
• Improved error handling and error description.
• Improved latency.

Header parameter

Sample header

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

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.

Request body

For a complete list of request parameters available for this endpoint, see the documentation on the availability endpoint.

Changes to existing behaviour

When you migrate to v1.1 of the OTA_HotelAvailNotif endpoint, you can see the following change in the API behaviour:

HTTP error code behaviour on v1.1

With the v1.1 of the OTA_HotelAvailNotif endpoint, we have standardised the treatment of the HTTP error codes. The following table captures all the common conditions and the HTTP error codes that the v1.1 endpoint returns.

New error codes on v1.1

The following table summarises the new error codes for the OTA_HotelAvailNotif endpoint.

Changes to the availability endpoint

We have rolled out few improvements to the B.XML availability endpoint.

The changes outlined in this section are applicable only when using the B.XML availability endpoint with a special header parameter. The following section covers only the changes available in v1.1. For a detailed explanation of the B.XML availability endpoint, see Create or update inventory, restrictions.

When migrating to the v1.1 B.XML availability endpoint, you get:

• To close a room type on a specified date. Even if roomrates are open, the room type is not available for booking.
• To update for periods in the future and up to one day in the past, in the Central European Time (CET) timezone.
• Accepts past date updates up to 1 day in the past (follows Central European Time (CET) timezone). Updates more than 1 day in the past returns a NOT_A_VALID_DATE error.
• Improved error handling and error description.
• Improved latency.

New behaviour

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 a partial success response with 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.

Similar to the v1.0 behaviour, 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.

Header parameter

Sample header

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

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.

Request body

For a complete list of request parameters available for this endpoint, see the documentation on the availability endpoint.

HTTP error code behaviour on v1.1

With the v1.1 of the B.XML availability endpoint, we have standardised the treatment of HTTP error codes. The following table captures all the common conditions and the HTTP error codes that the v1.1 endpoint returns.

Changes to existing error messages

The following table lists only the error codes that have changed for the B.XML availability endpoint.

New warnings on v1.1

The following table summarises the new warnings for the B.XML availability endpoint.

New error codes on v1.1

The following table summarises the new error codes for the B.XML availability endpoint.

Changes to the roomrates endpoint

We plan to roll out the improvements made to the B.XML roomrates endpoint as a new version, v1.1.

The changes outlined in this section are applicable only when using the B.XML roomrates endpoint with a special header parameter. For a detailed explanation of the v1.0 B.XML roomrates endpoint, see Retrieving active roomrates.

With the v1.1 B.XML roomrates endpoint, you can:

• Query roomrate details with or without rewritten rate details.
• Retrieve additional response details like flexible children prices, if they are set.
• See improved latency.

Also, in version v1.1:

• To resolve security issues and non-standard system behavior, the v1.1 roomrates endpoint supports the UTF-16 encoding algorithm.
• The endpoint returns all responses within the roomrates object.
• The endpoint doesn't return the max_children attribute anymore.
• The endpoint doesn't return the redundant follows_room_rate_properties attribute in the response while retrieving roomrates with rate relations.

Header parameter

Sample header

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

Additional body parameter

The following table includes a body parameter in addition to parameters supported in roomrates v1.0:

Sample request

<request>
 <hotel_id>123456</hotel_id>
 <support_rate_rewrite>0</support_rate_rewrite>
 <policy_override_start_date>2023-02-26</policy_override_start_date>
 <policy_override_end_date>2023-03-30</policy_override_end_date>
</request>

Response details

The endpoint returns the following flexible child rate details (if they are already defined) in addition to the details returned by roomrates v1.0.

Sample response

<roomrates>
   <rooms> 
     <room id="813518802" hotel_id="8135188" hotel_name="Deluxe HillTop Suites" max_children="0" room_name="Classic Quadruple Room">
        <rates>
            <rate id="25337348" fixed_occupancy="2" max_persons="5" policy="General" policy_id="343709190" rate_name="summer time rates">
                <meal_plan meal_plan_code="19"/>
                <policies>
                    <booking_rules>
                        <booking_rule max_advanced_booking_offset="P14D"/>
                        <booking_rule min_advanced_booking_offset="P1D"/>
                    </booking_rules>
                    <cancel_policy>
                        <cancel_penalty policy_code="43"/>
                    </cancel_policy>
                    <guarantee_payment_policy>
                        <guarantee_payment policy_code="166" effective_from="after_reservation_is_made" required="1"/>
                    </guarantee_payment_policy>
                </policies>
                <pricing type="OBP">
                  <additional_guests>
                    <price type="child" additional_guest_number="0" from_age="0" to_age="5" age_bucket_id="1" additional="0"/>
                    <price type="child" additional_guest_number="0" from_age="6" to_age="10" age_bucket_id="2" additional="40"/>
                    <price type="child" additional_guest_number="0" from_age="11" to_age="12" age_bucket_id="3" additional="60"/>
                  </additional_guests>
                </pricing>
            </rate>
        </rates>
       </room> 
    </rooms>
</roomrates>

Changes to MaxChildOccupancy attribute usage

We plan to change the way you can specify child occupancy settings for a room type or a unit using the OTA_HotelInvNotif endpoint from 20 March 2023.

This section captures the changes to the functionality for existing providers using the MaxChildOccupancy attribute within the OTA_HotelInvNotif endpoint and for new implementations.

Currently, the OTA_HotelInvNotif endpoint has three fields related to occupancy:

• MaxOccupancy: Specifies the maximum number of guests that can physically fit in the room.
• MaxAdultOccupancy: Specifies the maximum number of adults that can physically fit in the room.
• MaxChildOccupancy: Specifies the maximum number of children that are eligible for the children rate.

We plan to introduce an additional attribute MaxChildPayableOccupancy under TPA_Extensions to capture the number of children that are eligible for the children rate. Starting March 20, the value in the MaxChildOccupancy attribute no longer reflects the eligibility for children rates and instead specifies the physical child occupancy limit of the room type or unit.

Changes to existing implementations

The following changes are expected from March 20, 2023, for providers who are already using the MaxChildOccupancy attribute:

• MaxChildOccupancy: Specifies the maximum number of children that can physically fit in the room. There is no longer a limit of 4 children per room type/unit. However, the maximum number of children must be less than the MaxOccupancy value. This does not specify the number of children eligible for the children rate.
  We will use the existing value as the maximum child occupancy limit.
• MaxChildPayableOccupancy: Specifies the maximum number of children that are eligible for the children rate. Additional children are charged as adults.
  We will copy the existing value of MaxChildOccupancy attribute to the MaxChildPayableOccupancy attribute. If you have implemented child rates, by copying the value, we can retain the value of children eligible for the child rate.

New implementations

For all new implementations, the following behaviour is expected from March 20, 2023:

• MaxChildOccupancy: Specifies the maximum number of children that can physically fit in the room. There is no longer a limit of 4 children per room type/unit. However, the maximum number of children must be less than the MaxOccupancy value.
• MaxChildPayableOccupancy: Specifies the maximum number of children that are eligible for the children rate. Additional children are charged as adults.
  If you do not specify a value, the default value is set to 0 unless this value is updated in the extranet.
  

For more information on OTA_HotelInvNotif endpoint, see Managing room types.

Examples

The following section shows code snippets that specify the maximum occupancy and the number of children eligible for child rates using both the existing and new implementation.

Existing behaviour

The following code snippet sets the maximum number of children eligible for child rates to 2.

<OTA_HotelInvNotifRQ>
	<SellableProducts HotelCode="6314570">
		<SellableProduct InvNotifType="Overlay" InvCode="631457019">
			<GuestRoom>
				<Occupancy MaxOccupancy="6" MaxAdultOccupancy="3" MaxChildOccupancy="2"/>
				<Room RoomID="12345" />
				<Description>
					<Text>Apartment with Garden View</Text>
				</Description>
			</GuestRoom>
		</SellableProduct>
	</SellableProducts>
</OTA_HotelInvNotifRQ>

New behaviour

The following code snippet sets the maximum number of children that can physically fit in the room type to 3 and the maximum number of children eligible for child rates to 2.

<OTA_HotelInvNotifRQ>
	<SellableProducts HotelCode="6314570">
		<SellableProduct InvNotifType="Overlay" InvCode="631457019">
			<GuestRoom>
				<Occupancy MaxOccupancy="6" MaxAdultOccupancy="3" MaxChildOccupancy="3" />
                <TPA_Extensions>
                  <Occupancy MaxChildPayableOccupancy="2" />
                </TPA_Extensions>
				<Room RoomID="12345" />
				<Description>
					<Text>Apartment with Garden View</Text>
				</Description>
			</GuestRoom>
		</SellableProduct>
	</SellableProducts>
</OTA_HotelInvNotifRQ>

Changes to roomrateavailability endpoint

We plan to roll out the improvements made to the roomrateavailability endpoint soon.

The changes outlined in this section are applicable only when you use the test endpoint provided by your Connectivity account manager. This section covers only the changes based on the test endpoint. You can refer to the Rates & Availability documentation to know more about the existing functionalities.

Changes to the roomrateavailability endpoint

This section captures the latest changes to roomrateavailability available on the test endpoint. For a detailed explanation of the existing endpoint, see Retrieving rate and inventory details.

Test Endpoint

POST
https://supply-xml.booking.com/v1-beta/hotel/roomrateavailability

Request example

<request>
  <hotel_id>8011855</hotel_id>
  <room_id>801185502</room_id>
  <start_date>2022-11-02</start_date>
  <number_of_days>2</number_of_days>
</request>

[Old behaviour] Response example

<result>
    <roomrate booked="2" cancelled="0" closed="0" date="2022-11-02" min_contracted_rooms="0" min_contracted_rooms_until="0" rate_id="25279855" room_id="801185502" rooms_to_sell="8"/>
    <roomrate booked="2" cancelled="0" closed="0" date="2022-11-03" min_contracted_rooms="0" min_contracted_rooms_until="0" rate_id="25279855" room_id="801185502" rooms_to_sell="8"/>
    <roomrate booked="2" cancelled="0" closed="0" date="2022-11-04" min_contracted_rooms="0" min_contracted_rooms_until="0" rate_id="25279855" room_id="801185502" rooms_to_sell="8"/>
</result>

[New behaviour] Response example

<result>
    <roomrate booked="2" cancelled="0" closed="0" date="2022-11-02" min_contracted_rooms="0" min_contracted_rooms_until="0" rate_id="25279855" room_id="801185502" rooms_to_sell="8"/>
    <roomrate booked="2" cancelled="0" closed="0" date="2022-11-03" min_contracted_rooms="0" min_contracted_rooms_until="0" rate_id="25279855" room_id="801185502" rooms_to_sell="8"/>
</result>

Licences

We plan to deprecate the old Licences API features on February 15, 2022. You can find the features we plan to deprecate next to their alternatives:

Hotelier messages

We plan to deprecate sending hotelier messages using the Content API on February 15, 2022. You can find the features we plan to deprecate next to their alternatives:

Single property owner (SPO) flow

We plan to deprecate the SPO flow, which is creating an independent property without legal entity id, on September 15, 2021. You can find the features we plan to deprecate next to their alternatives:

Photos through HotelDescriptiveContentNotif (HDCN)

We plan to deprecate sending photos using the HotelDescriptiveContentNotif endpoint on September 15, 2021. You can find the features we plan to deprecate next to their alternatives: