Migrating to new versions

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

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.

Introducing Payments API v1.1

The Payments API now supports version 1.1. To understand the key changes, refer to the Version history documentation.

Introducing v1.3 of GET OTA_HotelProductNotif

We are introducing a few improvements to the GET OTA_HotelProductNotif endpoint in version 1.3.

This section covers:

• The deprecation timeline of the v1.0, v1.1, and v1.2 GET OTA_HotelProductNotif endpoints
• Comparison between the v1.0 and v1.3 GET OTA_HotelProductNotif endpoint
• Comparison between the v1.1 and v1.3 GET OTA_HotelProductNotif endpoint
• Comparison between the v1.2 and v1.3 GET OTA_HotelProductNotif endpoint

To use these improvements, specify v1.3 in the header parameter as outlined in the Header parameters section.

This section covers only the differences between earlier versions and v1.3 of the GET OTA_HotelProductNotif endpoint. For more information on the complete functionality of the GET OTA_HotelProductNotif endpoint, see Retrieving active roomrates.

Deprecation timeline for v1.0, v1.1, and v1.2 GET endpoints

With the launch of v1.3 GET OTA_HotelProductNotif endpoint, we plan to deprecate and sunset the v1.0, v1.1, and v1.2 GET OTA_HotelProductNotif endpoints by the following timeline.

What to expect after the deprecation and sunset date

• After the deprecation date, Booking.com will start sending deprecation warnings in the API response for v1.0, v1.1, and v1.2 GET OTA_HotelProductNotif API calls.
• After the sunset date, Booking.com will route all unversioned GET OTA_HotelProductNotif API calls to the v1.3 endpoint. Calls explicitly specifying v1.0, v1.1, or v1.2 will return an HTTP 400 Version is not supported error.

Header parameters

Comparison between v1.0 and v1.3

Comparison between v1.1 and v1.3

Comparison between v1.2 and v1.3

New response attributes

v1.3 returns the following new attributes on the <RatePlan> element:

Example response

<RatePlan RatePlanCode="11"
          PropertyBusinessModelId="12345"
          BusinessModel="net_rate"/>

What we expect from Connectivity Partners

Connectivity Partners should:

• Migrate to v1.3 before the sunset date.
• Use the Accept-Version header parameter and specify 1.3 when calling the GET OTA_HotelProductNotif endpoint.
• After the sunset date, calls without a version default to v1.3.
• Calling v1.0, v1.1, or v1.2 GET OTA_HotelProductNotif endpoints explicitly after the sunset date returns an HTTP 400 Version is not supported error response.

Introducing v1.3 of POST OTA_HotelProductNotif

We are introducing a few improvements to the POST OTA_HotelProductNotif endpoint in version 1.3.

This section covers:

• The deprecation timeline of the v1.0 POST OTA_HotelProductNotif endpoint
• Comparison between the v1.0 and v1.3 POST OTA_HotelProductNotif endpoint

To use these improvements, specify v1.3 in the header parameter as outlined in the Header parameters section.

This section covers only the difference between v1.0 and v1.3 of the POST OTA_HotelProductNotif endpoint. For more information on the complete functionality of the POST OTA_HotelProductNotif endpoint, see Managing roomrates.

Why the version upgrade from v1.0 to v1.3?

The GET OTA_HotelProductNotif endpoint is soon to launch v1.3. To maintain consistency between GET and POST endpoints, the POST endpoint version was aligned to v1.3.

The following is the expected behaviour when using the different version numbers:

• When calling v1.0, v1.1, or v1.2, the API routes to the v1.0 functionality until the sunset date.
• When calling v1.3, the API routes to the v1.3 functionality.

Deprecation timeline for v1.0 POST endpoint

With the launch of v1.3 OTA_HotelProductNotif endpoint, we plan to deprecate and sunset v1.0 POST OTA_HotelProductNotif endpoint by the following timeline.

What to expect after the deprecation and sunset date

• After the deprecation date, Booking.com will start sending deprecation warnings in the API response for v1.0 POST OTA_HotelProductNotif API calls.
• After the sunset date, Booking.com will automatically route unversioned POST OTA_HotelProductNotif API calls to v1.3 endpoint. Calls explicitly specifying v1.0, v1.1, or v1.2 will return an HTTP 400 Version is not supported error.

Header parameters

Comparison between v1.0 and v1.3

New validations

POST OTA_HotelProductNotif v1.3 includes the following new validations:

• ReleaseTimeOfDayStart must be less than ReleaseTimeOfDayEnd and cannot be equal.
• Property must have the correct pricing model enabled before using Length of Stay (LOS) or Occupancy-Based Pricing (OBP) for roomrates. For more information, see Pricing models.

What we expect from Connectivity Partners

Connectivity Partners should:

• Migrate to v1.3 before the sunset date.
• Use the Accept-Version header parameter and specify 1.3 when calling the POST OTA_HotelProductNotif endpoint.
• After the sunset date, calls without a version default to v1.3.
• Calling v1.0 POST OTA_HotelProductNotif endpoint explicitly after the sunset date returns an HTTP 400 Version is not supported error response.

Error response format

The following example shows the error response when calling a deprecated version after the sunset date:

<OTA_HotelProductNotifRS 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_HotelProductNotifRS.xsd" TimeStamp="2026-05-15T11:52:44+00:00" Target="Production" Version="1.004">
    <Errors>
        <Error Code="400" ShortText="Version is not supported"/>
    </Errors>
</OTA_HotelProductNotifRS>
<!-- RUID: [UmFuZG9tSVetc] -->

Troubleshooting error responses

This section lists the possible errors you might encounter while using the v1.3 OTA_HotelProductNotif endpoint.

Error codes

The following table summarises the error codes for the OTA_HotelProductNotif v1.3 endpoint.

Changes to the OTA_HotelRatePlanNotif endpoint

We rolled out the following changes to the v1.1 OTA_HotelRatePlanNotif endpoint:

• Supports creating a maximum of 200 active rate plans for a property.
• Doesn’t support Target attribute in the request body.
• Updated error description when a request tries to create a duplicate rate plan name.

For a detailed explanation of the OTA_HotelRatePlanNotif endpoint, see Managing rate plans.

Changes to the Messaging API

The Messaging API now supports two versions. To understand the key changes and implications when migrating to version 1.2, please refer to the Version 1.2 documentation.

Using Property management APIs along with Content API

The following section lists the recommended migration approach when using any of the following Property management APIs along with the Content API (HDCN endpoint):

• Property Details API
• Property Settings API
• Contacts API
• Property Facilities API
• Charges API
• Cancellation Policies

The Content API's default overlay behavior treats missing data in updates as intentional omissions. This can accidentally remove data you've set through the Property management APIs if you don't include the same data in subsequent HDCN requests.

To prevent this issue and maintain your new API's data even when it's not included in HDCN updates, Booking.com is introducing a set of domain_update_lock_<api_name> features.

The following table lists the Property management APIs and their corresponding feature names.

Using Rooms API along with OTA_HotelInvNotif API

If you are migrating from OTA_HotelInvNotif endpoint to Rooms API endpoints, Booking.com currently doesn't support a feature. We therefore recommend you to migrate to Rooms API and the Room facilities and Bathroom within the Facilities API in one go.

How to use the new domain update lock feature?

This section provides guidance on how to enable the domain update lock feature if you continue to use the Content API (OTA_HotelDescriptiveContentNotif) endpoint along with the Property management APIs.

1. Keep your existing HDCN request unchanged and continue to send the full HDCN request without omitting any details. When the feature is on we ignore the related updates in HDCN. Note that the request must be valid and pass existing validations.

2. Test the feature on a per-request basis. For example, when sending the request, attach to your HTTP Header Features value domain_update_lock_charges. You can specify multiple feature names separated by a comma to include multiple features at the same time. For more information, see Testing the features.

3. Once satisfied with the responses from both the OTA_HotelDescriptiveContentNotif and the Property management API, switch the feature on for all your requests using the Provider Portal.

   a. Navigate to the Provider Portal. Log in with your credentials. Click Administration -> Feature Management.

   b. Enable the features and click Save.

Using Property Details API along with Content API

To prevent your Property Details API related data from being accidentally updated via HDCN updates, Booking.com has introduced the domain_update_lock_property_general_info feature. This feature only applies to connectivity partners who have implemented the Property Details API.

Continue sending the full HDCN payload without omitting any information and enable the feature domain_update_lock_property_general_info after you have tested and implemented the Property Details API.

If you enable the feature domain_update_lock_property_general_info, subsequent HDCN calls will not make updates to the following fields.

For testing the features per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

Using Property Settings API along with Content API

Enable the following features once you have tested and implemented the related sections in the Property Settings API. With the features enabled, you can continue to send the full HDCN payload without omitting any information.

Once you have tested and implemented the full functionality of the Property Settings API, you can enable all the domain_update_lock_settings_* features.

Feature domain_update_lock_settings_general

If you enable the feature domain_update_lock_settings_general, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_pets

If you enable the feature domain_update_lock_settings_pets, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_sp

If you enable the feature domain_update_lock_settings_sp, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_accepted_pt

If you enable the feature domain_update_lock_settings_accepted_pt, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_cancel_ex

If you enable the feature domain_update_lock_settings_cancel_ex, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_age_buckets

If you enable the feature domain_update_lock_settings_age_buckets, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_cp

If you enable the feature domain_update_lock_settings_cp, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_invoice

If you enable the feature domain_update_lock_settings_invoice, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_french_taxes

If you enable the feature domain_update_lock_settings_french_taxes, subsequent HDCN calls will not make updates to the following fields.

Feature domain_update_lock_settings_rtb

If you enable the feature domain_update_lock_settings_rtb, subsequent HDCN calls will not make updates to the following fields.

For testing the features per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

Using Contacts API along with Content API

After fully migrating to Contacts API, you can enable the domain_update_lock_contacts feature to prevent HDCN updating data related to Contacts API. Subsequent HDCN calls will not make updates to the following fields.

For testing the feature per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

Using Facilities API along with Content API

Facilities API consists of 3 endpoints (Property Facilities, Room Facilities, Bathrooms).

Property Facilities are part of HDCN endpoint and can be locked using domain_update_lock_facilities feature.

Room facilities and Bathrooms are part of HIN endpoint, therefore, is not affected by this feature.

Once you start managing property facilities in Facilities API, you can choose to enable the feature for locking property facilities data domain updates in HDCN.

Once you enable the feature, subsequent HDCN calls will not make updates to the following fields.

For testing the feature per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

For more information on Facilities API, see Facilities API overview.

Using Charges API along with Content API

To prevent your Charges data from being accidentally deleted when it's not included in HDCN updates, Booking.com has introduced the domain_update_lock_charges feature.

If you enable the feature domain_update_lock_charges, subsequent HDCN calls will not make updates to the following fields.

For testing the feature per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

For more information on Charges API, see Charges API overview.

Using Policies API along with Content API

To prevent your Policy data from being accidentally deleted when it's not included in HDCN updates, Booking.com has introduced the domain_update_lock_cancellation_policies feature.

If you enable the feature domain_update_lock_cancellation_policies, subsequent HDCN calls will not make updates to the following fields.

For testing the feature per-request basis before enabling the feature using the Provider Portal, see Testing the features section.

For more information on Policy API, see Policy API overview.

Testing the features

Enabling the feature impacts all the properties that you manage. Before doing so, to test whether the HDCN call works as intended, pass the feature name in the Header of your HDCN request on a per-request basis.

For example:

curl --location 'https://supply-xml.booking.com/hotels/ota/OTA_HotelDescriptiveContentNotif' \
--header 'Content-Type: text/plain' \
--header 'Authorization: ••••••' \
--header 'Features: domain_update_lock_charges,domain_update_lock_facilities'

If you are satisfied with the feature behaviour, then enable it to omit/ignore any Charges and Facilities related data updates provided in subsequent HDCN calls.

Changes to the Derived Prices endpoint

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

• Setting the same value for both occupancy (in the persons attribute) and the leading_occupancy returns an OCCUPANCY_INVALID error with the following message: Occupancy should be positive, different than leading_occupancy, and lower than the room's capacity. Make sure to specify an occupancy value which is different from the leading_occupancy value.

For a detailed explanation of the /hotels/xml/derivedprices endpoint, see Create or update derived pricing rates.

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. Version 1.0 was sunset on June 10, 2024 and is no longer available.

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.

For a detailed explanation of the hotels/csv/los_pricing endpoint, see Create or update LOS pricing rates.

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

We have launched v1.1 of the roomrateavailability endpoint.

Using v1.1 roomrateavailability endpoint, you can additionaly view whether a room type is closed. For more information, see Retrieve inventory and rate details.

Changes to the OTA_HotelAvailNotif endpoint

We rolled out the following improvements to the v1.1 OTA_HotelAvailNotif endpoint:

• 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.

For a detailed explanation of the OTA_HotelAvailNotif endpoint, see Create or update inventory, restrictions.

Changes to the availability endpoint

We rolled out few improvements to the B.XML availability endpoint in version 1.1. Version 1.0 was sunset on January 15, 2024 and is no longer available.

Using 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.

For more information, see Create or update inventory, rates and restrictions.

Changes to the roomrates endpoint

We rolled out few improvements to the B.XML roomrates GET endpoint in version 1.1. Version 1.0 was sunset on January 15, 2024 and is no longer available.

For a detailed explanation of the v1.1 B.XML roomrates GET 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.

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: