Error: The rooms cannot be booked without executing the cancellation policies first.

Error Message

The rooms cannot be booked without executing the cancellation policies first.

What does this error mean?

This response indicates that the booking confirmation was blocked because the cancellation policies were not executed and recorded for the same booking attempt.

In the hotel booking flow, confirmation (DoBooking) depends on a previous step that validates and records the cancellation policies (getBookingConditions). This record is associated with the Token used for the booking attempt.

If DoBooking is sent with a Token that does not have this record, the system assumes that the cancellation policies were not executed and returns the error.

Most common symptoms

1. DoBooking returns HTTP 200, but the payload contains an Error object.
2. The message explicitly states that cancellation policies must be executed before booking.
3. The booking is not created, and the Rooms field may be returned as null.

Most common root cause

Token mismatch between requests.

Typical example:

• getBookingConditions was called with TOKEN_A
• DoBooking was called with TOKEN_B

Even if the hotel and room are the same, the cancellation policy record is tied to the Token. If the Token is not identical, validation fails.

Other possible causes

• getBookingConditions was executed with parameters that differ from those sent in DoBooking (hotel, room, dates, occupancy).
• The Token expired due to a delay between the steps.
• Parallel retries or multiple browser tabs caused the Token to be replaced during the booking flow.
• An old Token was reused from the integrator's session or cache.

How to resolve it

1. Repeat the flow, ensuring the following order:
   • Availability/Search
   • getBookingConditions
   • DoBooking
2. Ensure complete consistency between getBookingConditions and DoBooking:
   • Same Token
   • Same HotelId
   • Same RoomId
   • Same dates and occupancy
3. If retrying DoBooking:
   • Execute getBookingConditions again using the same Token as the retry, immediately before confirming the booking.

How to quickly confirm it in the logs

Compare the following fields in both requests:

• Token
• HotelId
• RoomId or RoomIds

If the Token is different, the cause is confirmed.

Recommended audit:

• Search the logs for a getBookingConditions request with the same Token as the failed DoBooking.
• If no such request exists, the flow either skipped this step or the Token was changed.

Prevention

• Do not reuse a Token across different booking attempts.
• Avoid parallel processing during checkout (two confirmations running simultaneously).
• When the room selection, dates, or occupancy are changed, generate a new Token and execute getBookingConditions again.
• Standardize Token storage in the integrator, always replacing the previous value in the user's session.

What to send to Support when assistance is required

For a complete analysis, please provide:

• ClientReference
• Token used in DoBooking
• Requests and responses for:
  • Availability/Search (where the Token was generated)
  • getBookingConditions
  • DoBooking
• Approximate time of the test and environment (production/staging)