Booking.com Tightens the Written Rules on Its Reporting API — and Fixes Cancellation Messages Again

Documentation corrections are easy to skip past. This one is worth reading, because if your integration was built against the previous wording, Booking.com has just told you that two fields you may have treated as optional were never optional at all.

Booking.com's connectivity changelog carried entries on 15 and 16 September 2026.

What changed on paper, not in the API

The 16 September entry covers the Reporting API. Booking.com now states in the documentation that:

• Every request must contain either report or stay_change
• price is required in every stay_change, and can be a non-negative decimal number — it is not restricted to integers
• Guest misconduct reports require misconduct_details with a non-empty details_text of at most 240 characters

The documentation previously described price and details_text as optional.

Booking.com also clarified the required property-damage fields and the optional damage_unavailable field, which defaults to 0 (no) when omitted.

The company is explicit that these are documentation corrections describing existing API behaviour, and that the API's validation behaviour has not changed. In practice that means the validation was always there — the docs simply did not say so.

A second cancellation-message fix in six weeks

The 15 September entry is a single bug fix. Booking.com says the system "now correctly returns cancellation messages again when using the Reservations API," logged as ACI-4695, and that fallback emails are working again.

That is the third cancellation-or-confirmation message fault disclosed on this changelog since August. The 18 August release fixed missing cancellation XML messages (ACI-4687), missing confirmation XML messages (ACI-4682) and cancellation messages returned with an unwanted RoomStay element (ACI-4680). The 1 September release fixed confirmation XML events that were never generated for reservations made before 4 August 2026 (ACI-4670, ACI-4700).

Why it matters

Reservation confirmation and cancellation messages are the layer a property management system relies on to know a booking is gone. When they go missing, the failure shows up at the property as a phantom reservation or a room that never gets released — and it shows up late. Four separate fixes in the same message pipeline across six weeks is a signal worth logging for anyone reconciling Booking.com reservations against their own records over that window.

Still on the horizon

The 4 August release remains the one with the largest downstream consequence: Request to Book (RtB) 2.0 changes the inventory model so connectivity partners must block availability as soon as a request is created, rather than only once it becomes a booking. Booking.com has published an RtB 2.0 overview and a migration guide. Guest withdrawals — where a guest cancels a pending request before the partner acts, moving it to WITHDRAWN_PENDING_APPROVAL — apply to both the 1.x inquiry flow and the 2.x RTB flow.

No deadline for RtB 2.0 migration was stated in the September entries.