When a guest sends an RTB request, you must block your property's availability immediately, before any reservation exists. This is the core difference from RtB 1.x, where you block availability only when the request becomes BOOKED.
As a Connectivity Provider (channel manager), that means keeping provider-side availability in sync across every channel you list the property on, so that a request received through Booking.com does not lead to a double-booking elsewhere.
For requests with requestType = RTB, use the RtB API as the source of truth for provider-side availability holds during the pre-booking flow. For such requests, the booking request itself represents an availability hold. When you later receive the reservation via the Reservations API, assume availability has already been managed by the RtB flow. Do not block it again.
For post-booking actions (such as cancellations or modifications), continue to use the Reservations API as the source of truth and follow your current availability logic. RtB 2.0 does not change post-booking flows.
For single-unit properties listed across multiple channels, blocking and releasing availability at the right moment prevents double-bookings.
For INQUIRY requests, do not change your availability when a request is created. Block availability only once the request transitions to BOOKED.
For RTB requests, block and release provider-side availability according to the request status:
| Request status | What it means | What you do |
|---|---|---|
CREATED | A new pending RtB 2.0 request was created. | Immediately block provider-side availability for the requested unit and dates, and sync the hold across your channels. |
APPROVED | Partner approved the request. Booking.com is creating the reservation. | Keep availability blocked. Do not change anything. |
BOOKED | Reservation successfully created. | Keep availability blocked. Do not block it again when you receive the reservation via the Reservations API. It was already blocked at CREATED. |
REJECTED | Partner rejected the request. | Release the provider-side availability you blocked at CREATED. |
EXPIRED_PENDING_APPROVAL | Partner did not respond in time; the request auto-expired. | Release provider-side availability. |
FAILED_TO_PROCESS | Partner approved, but Booking.com failed to create a reservation. | Release provider-side availability. No reservation will be created. |
WITHDRAWN_PENDING_APPROVAL | The guest withdrew the request while it was pending. | Release the provider-side availability you blocked at CREATED. See Handling guest withdrawals. |
The WITHDRAWN_PENDING_APPROVAL status is available in the RTB flow from API version 2.1.0. See Handling guest withdrawals and Versioning.
For RTB requests, monitor the request status and update your availability as it changes. Releasing a hold promptly on REJECTED, EXPIRED_PENDING_APPROVAL, FAILED_TO_PROCESS, and WITHDRAWN_PENDING_APPROVAL returns inventory to your other channels.