Booking.com retires a piece of your setup on Tuesday. Your existing rates are fine — your new ones might not be
On September 1 Booking.com switches off the old version of the connection that creates your room-and-rate-plan combinations, and the only sign at your property will be a new rate plan that never shows up
by Markus Busch
Driving the news. Booking.com's published deprecation table sets September 1, 2026 as the sunset date for two things your channel manager may still be running on: GET OTA_HotelProductNotif versions 1.0 through 1.2, and version 1.0 of its POST counterpart. Version 1.3 of the GET endpoint launched on June 8. The versions it replaced were marked deprecated on June 15 — seven days later. After Tuesday, any call that names one of those old versions comes back as HTTP 400 Version is not supported. Calls that name no version at all get routed forward to 1.3 automatically.
What this connection actually does. Booking.com calls the thing a roomrate: "a unique combination of room type, rate plan and conditions." Not the price. The product. This is the pipe that creates those combinations, changes them, removes them, and reads them back — the setup layer, where a room type gets married to a rate plan, a cancellation policy, and a mealplan.
Your nightly rates and availability travel somewhere else entirely, on OTA_HotelRateAmountNotif and OTA_HotelAvailNotif. Neither is affected. Everything already built and selling on Tuesday keeps selling on Wednesday.
The catch. Most providers will have migrated by now. Eleven weeks is real notice for routine version work, and a provider sending unversioned calls was never exposed at all — Booking.com routes those forward on its own. The exposure is narrow by construction: a provider that writes 1.0, 1.1 or 1.2 explicitly into its code.
How many still do? Booking.com doesn't publish it. Neither does anyone else. This piece can tell you where the problem would show up. It cannot tell you how big it is.
Why the date lands badly. September and October are build season. Next year's corporate rates. Winter packages. The room category you finished renovating in August. This is the stretch of the year when commercial teams create more products on Booking.com than at any other point, and the connection that creates products is the one expiring.
Picture the failure from your desk. There is no alarm. The error lands in your provider's logs. You ask for the negotiated rate you just closed in the RFP to be loaded, and a week later it still isn't there. You ask again. Somewhere in that fortnight you quietly form a view about how fast things get done around here, and the view is probably about the wrong thing.
Google is running a deadline into the same season, retiring third-party rates for hotel ads on September 30. Two pieces of platform housekeeping, one quarter, both reaching hotels through somebody else's software.
What it means for hotels. From Tuesday, treat anything newly created or changed on Booking.com as unconfirmed until you have looked at it yourself. Open the extranet. Check that the product exists, and that the mealplan, the policy, and the conditions hanging off it are the ones you asked for. A roomrate can arrive half-built.
And if something you requested in the first week of September doesn't land, you have a specific question available instead of a general complaint: which version of the product endpoint are we running.
Booking.com gave its content endpoints two years to retire. The one that builds your rate plans got eleven weeks.
Enjoying this analysis? Hospitality.today delivers daily insights on hotel distribution, AI trends, and travel commerce — straight to your inbox. Subscribe for free at Hospitality.today →