How to update the Booking.com API in your project

Start with the API your integration actually uses

This guide covers Booking.com Connectivity GET OTA_HotelProductNotif, which retrieves active roomrates. It does not cover the Demand API or every Booking.com integration. Before changing a version, identify the endpoint, HTTP method and configuration that your running application uses.

WATA Desktop helps you inspect that configuration in a local project folder. It repairs a limited set of recognizable version markers and leaves other findings for review.

Check the effective request version

Booking.com lists September 1, 2026 as the sunset date for GET versions 1.0–1.2. Its migration guide describes HTTP 400 responses for explicitly selected old versions and v1.3 as the default for unversioned GET requests. The documented way to select v1.3 is the Accept-Version header. Read Booking.com’s migration guide.

GET /hotels/ota/OTA_HotelProductNotif?HotelCode=YOUR_TEST_PROPERTY_ID HTTP/1.1
Host: supply-xml.booking.com
Accept-Version: 1.3

This is a manual request-configuration example, not an automatic WATA repair. Keep your integration’s existing authentication and use an authorized test property. The official endpoint reference describes the request.

Scan and repair supported references with WATA

1. Open your local project. Install WATA for Windows, connect your account and choose the folder containing the integration. Source files remain on your computer.
2. Run a scan and read the findings. Look for Booking.com endpoint references, the old version and any coverage warnings. A finding marked for review will not be repaired automatically.
3. Review the proposed configuration change. WATA 0.2.0 can update recognized endpoint-associated version tokens and matching XML configuration elements. The example below is application configuration, not the Booking.com request URL or payload.

Before:
<endpoint name="OTA_HotelProductNotif" version="1.2" method="GET" />

After the supported WATA edit:
<endpoint name="OTA_HotelProductNotif" version="1.3" method="GET" />

4. Create a backup and apply the supported repair. WATA verifies a backup before writing the change, then scans again.
5. Check the effective HTTP request separately. Confirm that the running application sends the intended Accept-Version. Changing a local marker does not establish that the application reads it.

Test response handling before deploying

Version 1.3 introduces PropertyBusinessModelId and BusinessModel on RatePlan. Upgrades from 1.1 also need a review of Value adds v2 identifiers. POST migrations have separate payload and policy requirements. These changes are described in the provider’s migration guide; WATA does not implement the related business logic.

• Compare a representative response with your parsing code and saved test fixtures.
• Check room, rate-plan and business-model mappings used downstream.
• Run your integration tests with authorized test data. Review detected project scripts before allowing WATA to run them.
• Inspect the local change diff. If a supported edit needs to be undone, use the verified backup to restore it.

Common questions

Can WATA update my whole Booking.com integration automatically?

No. It automates supported local version-marker replacements. Request negotiation, response changes, authentication and business rules still need engineering review.

Will my project be uploaded?

WATA keeps project code, paths and backups on your computer. The online account service authorizes operations and records usage counters. Read the data and access details.

How long does the migration take?

The configuration edit may be small, but the work depends on your integration and tests. WATA does not promise a fixed completion time or production compatibility.