Deprecation and sunsetting

Page last updated on April 04, 2022

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:

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.

Solution Deprecation date Sunsetting date
Single property owner (SPO) flow September 15, 2021 April 1, 2022
Photos via Content API September 15, 2021 April 1, 2022
One past stay (Guest Requirement) September 15, 2021 April 1, 2022
Hotelier message February 15, 2022 April 20, 2022
Licences via Content API February 15, 2022 April 20, 2022
Children policies via Content API February 15, 2022 April 20, 2022

Detailed overview of deprecating solutions

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

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.

Photos via Content API

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

→ 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:

For this element, there exists no alternative solution.

Hotelier message

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

→ To learn more about the alternative solution, see the Property profile 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.

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):

deprecation-timeline

  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.