Deprecation and sunsetting

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