Deprecation and sunsetting

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

To add value and improve partner experience, Booking.com continually strives to provide the best API solutions. As new API solutions are introduced, the old functionality is gradually deprecated and finally sunset (no longer available for use). For an accurate definition of what Booking.com means by deprecated and/or sunset, see deprecation policy definitions.

This page provides information on a list of solutions that Booking has planned to deprecate and/or sunset and their timeline. At Booking.com, it is not just about discontinuing old solutions, but adding value by offering alternate or more efficient solutions to benefit your business.

Overview of content

This page provides information on the following topics:

• The list of solutions that Booking.com plans to deprecate and/or sunset and their timeline.
• The details of each deprecating solution.
• The key definitions regarding deprecation and sunsetting.
• An example timeline for the deprecation process with more in-depth explanations on what to expect at each given step.
• Deprecated APIs return warning response
• Sunset APIs return error response

Deprecation and sunsetting dates

You can see an overview of the solutions with their deprecation and sunsetting dates in the following table. To learn more and see a detailed overview of each solution, click on the respective solution.

→ To learn what deprecation and sunsetting means, see deprecation policy definitions

→ To help you migrate to an alternative solution (if applicable), see migration guides.

Detailed overview of deprecating solutions

This section provides in-depth information on the functionality that is deprecated within each affected solution.

Introducing the GET OTA_HotelProductNotif endpoint version

Booking.com is releasing a new and improved GET OTA_HotelProductNotif endpoint version 1.3 on Jun 08, 2026 as part of its ongoing API modernisation efforts.

We plan to deprecate the old versions 1.0, 1.1, and 1.2 by June 15, 2026, and subsequently sunset their support by September 1, 2026.

For more information on how to migrate to the v1.3 GET OTA_HotelProductNotif, see Introducing v1.3 of GET OTA_HotelProductNotif.

Introducing the POST OTA_HotelProductNotif endpoint version

Booking.com is releasing a new and improved POST OTA_HotelProductNotif endpoint version 1.3 on April 28, 2026 as part of its ongoing API modernisation efforts.

We plan to deprecate the old version 1.0 by May 15, 2026, and subsequently sunset its support by September 1, 2026.

For more information on how to migrate to the v1.3 POST OTA_HotelProductNotif, see Introducing v1.3 of OTA_HotelProductNotif endpoint.

Deprecating legacy max payable child field

Booking.com plans to deprecate the legacy max payable child field on June 23, 2026 and sunset it on June 29, 2026.

This field is currently available as max_children_that_pay_children_rate in the Rooms API and MaxChildPayableOccupancy in the OTA_HotelInvNotif endpoint. It defines how many children in a room are eligible for the child rate and also affects whether a room can appear in family search results.

After June 29, 2026, child rates apply to all children allowed by the room. The legacy max payable child field will no longer affect pricing or family search eligibility.

For example, if a room allows up to 3 children through max_children or MaxChildOccupancy, but the legacy max payable child field is set to 1, only 1 child is currently eligible for the child rate. In searches with 2 or 3 children, the additional children are treated with adult pricing. If adult pricing for those extra children does not exist for that room setup, the room might not be shown in family search results at all. After the sunset, that room can appear in those family searches, and child rates apply to all 3 children.

This change provides the following benefits:

• Simpler setup with one clear rule: Going forward, child rates apply to all children allowed by the room as defined by max_children or MaxChildOccupancy field.
• Fewer bugs and support cases by removing edge cases where extra children were priced as adults or rooms did not appear in family searches.
• Better performance for properties because more family combinations can find and book available rooms.

If you currently use this field, remove it from your product surface and validate your pricing and family search flows before June 29, 2026. Otherwise, your integration will see modified family search and pricing behaviour because Booking.com will ignore this field after the sunset date.

For more information on child pricing and occupancy, see Setting up children policies and child rates (pricing).

Introducing the new OTA_HotelRatePlanNotif endpoint version

Booking.com has released a new and improved OTA_HotelRatePlanNotif endpoint version 1.1 as part of its ongoing API modernisation efforts.

We plan to deprecate the old version 1.0 by October 13, 2025, and subsequently sunset its support by January 29, 2026.

For more information on how to migrate to the v1.1 OTA_HotelRatePlanNotif, see Changes to the OTA_HotelRatePlanNotif endpoint.

Generation of authorization tokens for messaging

Booking.com will deprecate the GET /hotels/json/messaging-auth endpoint on October 8, 2025 and will sunset it on December 15, 2025.

To support special & structured request through messaging, use the Messaging API v1.2.

OTA_HotelDescriptiveContentNotif (HDCN) endpoint in Content API

Booking.com has deprecated the OTA_HotelDescriptiveContentNotif (HDCN) endpoint on December 31, 2024 and will sunset it on December 31, 2026.

To understand how to integrate with our recommended new modular APIs, see Making property onboarding easier.

OTA_HotelSummaryNotif (HSN) endpoint in Content API

Booking.com has deprecated the OTA_HotelSummaryNotif (HSN) endpoint on December 31, 2024 and will sunset it on December 31, 2026.

For details on implementing the Property API status endpoint, please refer to the Property API's status endpoint documentation.

OTA_HotelInvNotif (HIN) endpoint in Content API for Home providers

Booking.com has deprecated the OTA_HotelInvNotif (HIN) endpoint on December 31, 2024 and will sunset it on December 31, 2026 for Home providers.

Home providers should implement the Rooms API and the Facilities API (specifically the room facilities and bathroom endpoints) at their earliest convenience.

To find out more about our new modular APIs, see our guide on Making property onboarding easier.

OTA_HotelDescriptiveInfo (HDI) endpoint in Content API for Home providers

Booking.com has deprecated the OTA_HotelDescriptiveInfo (HDI) endpoint on December 31, 2024 and will sunset it on December 31, 2026 for Home providers.

We strongly encourage Home providers to implement new modular APIs at their earliest convenience, which will enable them to retrieve relevant property information using the GET method.

To learn more about our new modular APIs, see our guide on Making property onboarding easier.

House Rules in Content API

Booking.com has deprecated the house rules endpoints, namely the POST /house-rules/properties/{property_id} and the GET /house-rules/properties/{property_id} endpoints, on December 31, 2024 and will sunset them on December 31, 2026.

The same functionality is available in the new Property Settings API. To learn more, see Managing property settings.

Reply Score in Property Score API

Booking.com is deprecating the Reply score field (reply_score) from the Property Scores API response.

As of 30 April 2025, the reply score field will no longer return a value. After the sunsetting date of 02 July 2025, the API does not return the reply-score field in the response.

For more information, see Managing property scores.

Introducing Token-based Authentication

To secure the machine-to-machine communication process, Booking.com is introducing a new two-legged token-based authentication method.

Token-based authentication introduces an extra layer of protection. You provide your encrypted client ID and client secret once to receive an encoded token that you can then use to call our APIs until the token expires (one hour). You can generate 30 tokens per hour.

We plan to deprecate the credential-based authentication scheme by June 30, 2025 and sunset it by December 31, 2025.

For more information on:

• How to migrate your accounts to use the token-based authentication method, see the How do you migrate to a Token-based Authentication method? section.
• The authentications methods, see the Authentication topic.

Introducing the new derivedprices endpoint version

Booking.com has released a new and improved /hotels/xml/derivedprices endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by February 14, 2025, and subsequently sunset its support on May 5, 2025.

For more information, see the Changes to the Derived Prices endpoint section in the Migration guide.

Sustainability Practices as Facilities

Booking.com is deprecating the Sustainability facilities. If you send a request containing Services with codes from one of the Sustainability services:

• Before 13 December 2024: you will receive a warning
• After 13 December 2024: your request will be rejected

Introducing the new los_pricing endpoint version

Booking.com has released a new and improved /hotels/csv/los_pricing endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by April 01, 2024, and subsequently sunset its support by June 10, 2024.

For more information, see the Changes to the LOS pricing endpoint v1.1. section in the Migration guide.

Introducing the new OTA_HotelRateAmountNotif endpoint version

Booking.com has released a new and improved OTA_HotelRateAmountNotif endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by January 31, 2024, and subsequently sunset its support by February 14, 2024.

For more information on how to migrate to the v1.1 OTA_HotelRateAmountNotif, see Changes to the OTA_HotelRateAmountNotif endpoint.

Introducing the new OTA_HotelAvailNotif endpoint version

Booking.com has released a new and improved OTA_HotelAvailNotif endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by January 31, 2024, and subsequently sunset its support by February 14, 2024.

For more information on how to migrate to the v1.1 OTA_HotelAvailNotif, see Changes to the OTA_HotelAvailNotif endpoint.

Introducing the new availability endpoint version

Booking.com has released a new and improved B.XML availability endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by December 06, 2023, and subsequently sunset its support by January 15, 2024.

For more information on how to migrate to the B.XML v1.1 availability, see Changes to the availability endpoint.

Introducing the new roomrates endpoint version

Booking.com has released a new and improved B.XML roomrates endpoint version 1.1 as part of its ongoing API modernisation efforts. We plan to deprecate the old version 1.0 by December 06, 2023, and subsequently sunset its support by January 15, 2024.

For more information on how to migrate to the B.XML roomrates v1.1, see Changes to the roomrates endpoint.

Specifying attractions and property's relative position information in Content API

Booking.com is deprecating the functionality of specifying nearby attractions and the property's relative position information using AreaInfo and HotelInfo > RelativePositions as of March 15, 2023. Booking.com automatically generates the nearby places and the property's relative position information. The functionality will sunset on June 30, 2023.

With this change, the OTA_HotelDescriptiveContentNotif and OTA_HotelDescriptiveInfo endpoints would soon stop supporting the usage of AreaInfo and HotelInfo > RelativePositions elements.

For more information, see AreaInfo and HotelInfo topics.

China channel via Promotions API

Booking.com has deprecated the China channel for promotions that are not geo rates (Promotions API) on October 5, 2022 and will sunset it December 7, 2022. You can still set the channel to China before it becomes sunset, but this has no longer an impact on guests making reservations through Booking.com.

Business Booker rates via Promotions API

Booking.com will remove existing Business Booker rates on July 29 2022, which means starting that day guests will no longer see these rates when using the Booking.com search engine. Booking.com therefore also deprecates managing Business Booker rates via the Promotions API in the following ways:

• Creating promotions of the type business_booker using the /hotels/xml/promotions endpoint (GET).
• Updating promotions of the type business_booker using the /hotels/xml/promotions endpoint (POST).
• Deactivating promotions with IDs that refer to promotions of the type business_booker using the /hotels/xml/promotions endpoint (DEL).
• Activating promotions with IDs that refer to promotions of the type business_booker using the /hotels/xml/promotions endpoint (POST).
• Retrieving promotion details of the type business_booker using the /hotels/xml/getpromotions endpoint (POST).
• Retrieving the promotion channels of type business_booker using the /hotels/xml/getpromotionchannels endpoint (POST).

→ You can still enable your properties to make use of all other promotion types. To learn more about the alternative solutions, and how they could benefit your properties see the Promotions API documentation.

Licences via Content API

Booking.com deprecates managing licences using the Content API in the following ways:

• Sending room type-level licence numbers via the LicenseNumber attribute in the Room element or sending TPA_Extensions/LicenseInfos using the OTA_HotelInvNotif endpoint.
• Retrieving room type-level licence numbers via the LicenseNumber attribute in the Room element or GuestRoom/TPA_Extensions/LicenseInfos using the OTA_HotelDescriptiveInfo endpoint.
• Sending room type-level licence information via the LicenseInfos element using the OTA_HotelDescriptiveInfo endpoint.
• Retrieving room type-level licence information via the LicenseNumber LicenseInfos element using the OTA_HotelDescriptiveInfo endpoint.
• Sending property-level licence information via the PropertyLicenseType, PropertyLicenseIssueDate, and PropertyLicenseType attributes in the HotelDescriptiveContent element using the OTA_HotelDescriptiveContentNotif endpoint.
• Retrieving property-level licence information via the PropertyLicenseType, PropertyLicenseIssueDate, and PropertyLicenseNumber attributes in the HotelDescriptiveContent element within the using the OTA_HotelDescriptiveInfo endpoint.

→ To learn more about the alternative solution, see the new Licences API documentation.

Children policies via Content API

Booking.com deprecates the sending of children prices via the OTA_HotelDescriptiveContentNotif endpoint in the following ways:

• Using Code="218" in the Service element using the OTA_HotelDescriptiveContentNotif endpoint.
• Using Code="5038" in the Service element using the OTA_HotelDescriptiveContentNotif endpoint.

→ To learn more about the alternative solution, see setting up children policies and prices.

SPO flow

Booking.com deprecates using the Single Property Owner flow to create an independent property using the OTA_HotelDescriptiveContentNotif endpoint without legal entity ID (or without legal contact email with feature turned on).

→ To learn more about the alternative solution, see the Contracting API documentation.

Hotelier message

Booking.com deprecates using HotelierMessage within the HotelInfo, FacilityInfo and AreaInfo elements in the following ways:

• Sending hotelier messages using the OTA_HotelDescriptiveContentNotif endpoint.
• Retrieving hotelier message info using the OTA_HotelDescriptiveInfo endpoint.

→ To learn more about the alternative solution, see the Property profile API documentation.

Photos via Content API

Booking.com deprecates managing photos using the Content API. This impacts:

• Uploading photos using the MultimediaDescriptions element within the OTA_HotelDescriptiveContentNotif endpoint.
• Uploading photos using the Image elements within the HotelInvNotif endpoint.
• Retrieving photos using the HotelDescriptiveInfo endpoint.

→ To learn more about the alternative solution, see the Photo API documentation.

One past stay

Booking.com is deprecating the RequireMinimumStay attribute in the GuestInformation element. This impacts:

• Sending the RequireMinimumStay attribute in the GuestInformation element using the OTA_HotelDescriptiveContentNotif endpoint.
• Retrieving the RequireMinimumStay attribute in the GuestInformation element using the OTA_HotelDescriptiveInfo endpoint.

For this element, there exists no alternative solution.

Key definitions

This section covers the definitions for all concepts related to deprecation.

• Solution: From here on, solution refers to any API product, feature, or service that Booking.com provides to you via the Connectivity platform. In practice, this often refers to an entire endpoint, part of an endpoint, or just one attribute.
• Deprecation: Deprecating a solution means Booking.com no longer intends to improve or update that solution. Additionally, Booking.com no longer actively supports its:
  - usage (both technical and commercial)
  - implementation, and
  - improvement.
  You can still use the solution marked for deprecation, but are strongly encouraged to move to an alternative solution. Booking.com can still fix business critical bugs (breakage that could impact your business continuity) related to the deprecated solution.
• Sunsetting: Sunsetting a solution means that Booking.com no longer enables you to use it, which basically means the solution is no longer available.
• Deprecation announcement: This is the moment Booking.com communicates to you the deprecation and sunsetting plans for (a) solution(s). Booking.com intends to announce this in a timely manner so that you can plan ahead and implement the alternative solution (if applicable).
• Deprecation date: Refers to the moment in time in which the deprecation of (a) solution(s) starts.
• Deprecation period: Refers to the time period in which a solution is deprecated.
• Sunset date: Refers to the date (end of deprecation period) in which Booking.com pulls the plug on a solution. This means Booking.com no longer enables you to use the solution.
• Migration guide: Refers to documentation that aims to support you in migrating to the alternative solution (if applicable) when a solution is deprecated.
• Deprecation timeline: The deprecation timeline consists of the deprecation date, sunset date, and documentation removal date.
• Documentation archival: Any supporting documentation for the solution is now archived. This is the end of the deprecation process.

Deprecation timeline (example)

To understand the deprecation timeline, see the following figure (with more detailed steps below):

1. Booking.com informs you about the solution(s) and their timeline for deprecation and sunsetting. Booking.com can use multiple communication channels, such as: Release cycle newsletter, dedicated documentation section, Salesforce Communities, and the provider portal.
2. After communication, Booking.com creates a migration guide(s) or other information resources to help you migrate to the alternative solution (if applicable).
3. A month before deprecation, Booking.com sends you reminders via the newsletter and communities. It is recommended to start planning for the changes within your systems or interface.
4. On or past the deprecation date, Booking.com no longer supports the solution(s) marked for deprecation, unless they are business critical. (For example, photos via Content API are blocked from being uploaded is business critical, while longer waiting time for processing uploads is not.) Relevant pages in the documentation carry a banner with a deprecation note. API responses also include warnings with deprecation messages.
5. During the deprecation period, Booking.com sends targeted reminders to ensure that you are aware and are able to mitigate the impact of the deprecation. When in trouble, please reach out to support. They can still help with implementation of the alternative solution (if applicable).
6. On or past the sunset date, Booking.com removes the functionality from active use. When used, the API returns an error response.
7. As a final step in the process, Booking.com archives the documentation and removes any instances where the solution is present (such as the partner programme).

Deprecated APIs return warning response

Starting the day of the deprecation, all affected API endpoints return (a) warning(s):

• For cases when it concerns the deprecation of an entire endpoint, the warnings are in the header.
• For cases when it concerns a partial deprecation of an endpoint, you can find deprecation warnings in the <warnings> or "warnings" array in the response body.

Sunset APIs return error response

Calling an API endpoint or element(s) within an endpoint after their sunset date returns an error with an HTTP status 400, Bad request response.

Need help?

If a solution deprecation affects you, we can support you with migrating to the alternative solution or provide insights in how to mitigate the impact of the changes on your internal set-up. If you feel you need more support, do not hesitate to reach out to Connectivity Support or your Booking.com contact person.