# Availability management

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.

## Pre-booking vs. post-booking: which API to follow

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.

## Status-based availability rules

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](/connectivity/docs/request-to-book/withdrawal). |


The `WITHDRAWN_PENDING_APPROVAL` status is available in the RTB flow from API version `2.1.0`.
See [Handling guest withdrawals](/connectivity/docs/request-to-book/withdrawal) and [Versioning](/connectivity/docs/request-to-book/technical-overview#versioning).

Continuously monitor status
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.