# 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](#key-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.](#deprecation-and-sunsetting-dates)
* [The details of each deprecating solution.](#detailed-overview-of-deprecating-solutions)
* [The key definitions regarding deprecation and sunsetting.](#key-definitions)
* [An example timeline for the deprecation process with more in-depth explanations on what to expect at each given step.](#deprecation-timeline-example)
* [Deprecated APIs return warning response](#deprecated-apis-return-warning-response)
* [Sunset APIs return error 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](#key-definitions)

→ To help you migrate to an alternative solution (if applicable), see [migration guides.](/connectivity/docs/migration-guides/migrating-to-new-versions)

| Solution | Deprecation date | Sunsetting date |
|  --- | --- | --- |
| [Deprecating legacy max payable child field](#deprecating-legacy-max-payable-child-field) | June 23, 2026 | June 29, 2026 |
| [Version 1.0 of the `OTA_HotelRatePlanNotif` endpoint](#introducing-the-new-ota_hotelrateplannotif-endpoint-version) | October 13, 2025 | January 29, 2026 |
| [Generation of authorization tokens for messaging](#generation-of-authorization-tokens-for-messaging) | October 8, 2025 | December 15, 2025 |
| [`OTA_HotelDescriptiveContentNotif` (HDCN) endpoint in Content API](#ota_hoteldescriptivecontentnotif-hdcn-endpoint-in-content-api) | December 31, 2024 | December 31, 2026 |
| [`OTA_HotelSummaryNotif` (HSN) endpoint in Content API](#ota_hotelsummarynotif-hsn-endpoint-in-content-api) | December 31, 2024 | December 31, 2026 |
| [`OTA_HotelInvNotif` (HIN) endpoint in Content API for Home providers](#ota_hotelinvnotif-hin-endpoint-in-content-api-for-home-providers) | December 31, 2024 | December 31, 2026 |
| [`OTA_HotelDescriptiveInfo` (HDI) endpoint in Content API for Home providers](#ota_hoteldescriptiveinfo-hdi-endpoint-in-content-api-for-home-providers) | December 31, 2024 | December 31, 2026 |
| [House Rules in Content API](#house-rules-in-content-api) | December 31, 2024 | December 31, 2026 |
| [Credential-based authentication scheme](#introducing-token-based-authentication) | June 30, 2025 | December 31, 2025 |
| [`currencies` endpoint](/connectivity/docs/b_xml-currencies) | June 22, 2025 | September 22, 2025 |
| [Reply Score in Property Score API](#reply-score-in-property-score-api) | April 30, 2025 | July 2, 2025 |
| [Version 1.0 of the `/hotels/xml/derivedprices` endpoint](#introducing-the-new-derivedprices-endpoint-version) | February 14, 2025 | May 5, 2025 |
| [Sustainability facilities](#sustainability-practices-as-facilities) | October 11, 2024 | December 13, 2024 |
| [Version 1.0 of the `/csv/los_pricing` endpoint](#introducing-the-new-los_pricing-endpoint-version) | April 01, 2024 | June 10, 2024 |
| [Version 1.0 of the `OTA_HotelRateAmountNotif` endpoint](#introducing-the-new-ota_hotelrateamountnotif-endpoint-version) | January 31, 2024 | February 14, 2024 |
| [Version 1.0 of the `OTA_HotelAvailNotif` endpoint](#introducing-the-new-ota_hotelavailnotif-endpoint-version) | January 31, 2024 | February 14, 2024 |
| [Version 1.0 of the B.XML `availability` endpoint](#introducing-the-new-availability-endpoint-version) | December 06, 2023 | January 15, 2024 |
| [Version 1.0 of the B.XML `roomrates` endpoint](#introducing-the-new-roomrates-endpoint-version) | December 06, 2023 | January 15, 2024 |
| [Specifying attractions and the property's relative position information](/connectivity/docs/deprecation-policy/deprecation-and-sunsetting#specifying-attractions-and-propertys-relative-position-information-in-content-api) | March 15, 2023 | June 30, 2023 |
| [China channel via Promotions API](#china-channel-via-promotions-api) | October 5, 2022 | December 7, 2022 |
| [Business Booker rates via Promotions API](#business-booker-rates-via-promotions-api) | July 29, 2022 | September 16, 2022 |
| [Licences via Content API](#licences-via-content-api) | February 15, 2022 | April 20, 2022 |
| [Children policies via Content API](#children-policies-via-content-api) | February 15, 2022 | April 20, 2022 |
| [Hotelier message](#hotelier-message) | February 15, 2022 | April 20, 2022 |
| [Single property owner (SPO) flow](#spo-flow) | September 15, 2021 | April 1, 2022 |
| [Photos via Content API](#photos-via-content-api) | September 15, 2021 | April 1, 2022 |
| [One past stay (Guest Requirement)](#one-past-stay) | September 15, 2021 | April 1, 2022 |


## Detailed overview of deprecating solutions

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

### 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`](/connectivity/docs/rooms-api/managing-units) in the Rooms API and [`MaxChildPayableOccupancy`](/connectivity/docs/setting-up-children-policies-and-pricing#using-the-hotelinvnotif-endpoint) 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)](/connectivity/docs/setting-up-children-policies-and-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.](/connectivity/docs/migration-guides/migrating-to-new-versions/#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](/connectivity/docs/messaging-api/version-history#version-1.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](https://connectivity.booking.com/s/solution-article/content-api-modernisation-MCP2RH5PDI6VHN5HU3ECL2FER2TY?language=en_US).

### `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](/connectivity/docs/property-api/status-endpoint/status-introduction#property-apis-status-endpoint).

### `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](/connectivity/docs/rooms-api/introduction-to-rooms-api) and the Facilities API (specifically the [room facilities](/connectivity/docs/content-api-modules/facilities-api/manage-room-facilities#managing-room-facilities) and [bathroom](/connectivity/docs/content-api-modules/facilities-api/manage-bathrooms#managing-bathroom-facilities) endpoints) at their earliest convenience.

To find out more about our new modular APIs, see our guide on [Making property onboarding easier](https://connectivity.booking.com/s/solution-article/content-api-modernisation-MCP2RH5PDI6VHN5HU3ECL2FER2TY?language=en_US).

### `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](https://connectivity.booking.com/s/solution-article/content-api-modernisation-MCP2RH5PDI6VHN5HU3ECL2FER2TY?language=en_US).

### 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](/connectivity/docs/content-api-modules/property-details-api/implementing-property-api-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.](/connectivity/docs/property-scores-api/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?](https://connectivity.booking.com/s/article/Guide-to-creating-machine-accounts-with-Token-based-Authentication?language=en_US) section.
- The authentications methods, see the [Authentication](/connectivity/docs/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](/connectivity/docs/migration-guides/migrating-to-new-versions#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](/connectivity/docs/codes-hac#sustainability-codes):

* 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.](/connectivity/docs/migration-guides/migrating-to-new-versions#changes-to-the-los-pricing-endpoint) 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.](/connectivity/docs/migration-guides/migrating-to-new-versions/#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.](/connectivity/docs/migration-guides/migrating-to-new-versions/#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.](/connectivity/docs/migration-guides/migrating-to-new-versions/#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.](/connectivity/docs/migration-guides/migrating-to-new-versions/#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](/connectivity/docs/api-reference/areainfo) and [HotelInfo](/connectivity/docs/api-reference/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.](/connectivity/docs/promotions)

### 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.](/connectivity/docs/licences-api/understanding-the-licences-api)

### 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.](/connectivity/docs/setting-up-children-policies-and-pricing/#new-version-setting-up-children-policies-and-child-rates-pricing)

### 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.](/connectivity/docs/contracting-api/managing-contracts)

### 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.](/connectivity/docs/tsk-create-property)
* Retrieving hotelier message info using the [OTA_HotelDescriptiveInfo endpoint.](/connectivity/docs/tsk-retrieve-property)


→ To learn more about the alternative solution, see [the Property profile API documentation.](/connectivity/docs/property-profile-api/#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.](/connectivity/docs/tsk-retrieve-property)


→ To learn more about the alternative solution, see [the Photo API documentation.](/connectivity/docs/photo-api/understanding-the-photo-api)

### 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.](/connectivity/docs/tsk-create-property)
* Retrieving the `RequireMinimumStay` attribute in the `GuestInformation` element using [the `OTA_HotelDescriptiveInfo` endpoint.](/connectivity/docs/tsk-retrieve-property)


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

![deprecation-timeline](/assets/deprecation-timeline.21f48cc7e78b09b1f9540f7ddb07fcc172805dee8f8b450cf2a3761beb7fe20c.6a743ed3.png)

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](https://connectivity.booking.com/s/article/Contact-Us?language=en_US) or your Booking.com contact person.