# Self-assessment

Before going live, set up a test property and validate your RtB 2.0 integration against the
scenarios below. For each step, note the RUID of the relevant API calls and share the details with
your Booking.com contact.

## Set up a test property

Before running the scenarios, set up a test property that is eligible for RtB 2.0 and create test
requests against it.

### Create an eligible test property

Make sure your test property meets all of the following criteria:

* **Property creation** – Create a new test property using the new Property API or the legacy
Content API.
* **Location** – The property must be in one of the supported launch markets: US, AU, FR, ES,
UK, DE, or IT.
* **Accommodation type** – Only specific accommodation types are allowed – for example
holiday home, apartment, or villa (hotel categories `5006`, `3`, and `35`).
* **Payment** – The property must use the *Payments by Booking* or hybrid payment models.
Properties that exclusively offer *Pay at the Property* are not eligible. Enable this in the
Extranet (Finance menu → *Payments by Booking.com* → *Sign up now*) or via the Payments
by Booking API.
* **Enable Request to Book** – Specify
`<TPA_Extensions><BookingModel Type="RTB" /></TPA_Extensions>` using the Content API, or
`"booking_model": {"type": "RTB"}` using the Property Settings API.
* **Allowlist your test property** – Contact the Booking.com team via the dedicated Slack
channel to allowlist your test property.


### Create test booking requests

To create test RtB requests for your test property, use the following Booking.com frontend URL,
replacing `{property_id}` with your test property ID:

```
https://secure.booking.com/book.html?test=1;hotel_id={property_id}
```

This requires a login, only works for test properties, and the check-in date must be at least two
days in the future.

Because the new flow requires the property to be on Payments by Booking, provide a test credit card
or use your own. You can set a free cancellation policy for your test property and cancel the
booking at any time to avoid charges.

## Scenario 1: Happy flow (`APPROVED` → `BOOKED`)

1. Create a new `RTB` booking request for a test property.
2. Pull the new request via the RtB Connectivity API and note the RUID.
3. Block provider-side availability and propagate it across your other channels. Note the RUID of
the Rates & Availability API call.
4. Update the booking request status to `APPROVED` via the RtB Connectivity API and note the RUID.
5. Pull the updated request via the RtB Connectivity API and note the RUID and the reservation ID.
6. Confirm you did **not** re-block availability when receiving the reservation via the Reservations
API.


## Scenario 2: Partner declines the request (`REJECTED`)

1. Create a new `RTB` booking request for a test property.
2. Pull the new request via the RtB Connectivity API and note the RUID.
3. Block provider-side availability and propagate it across your other channels. Note the RUID of
the Rates & Availability API call.
4. Update the booking request status to `REJECTED` via the RtB Connectivity API and note the RUID.
5. Verify that provider-side availability is released and propagated correctly. Note the RUIDs of the
relevant Rates & Availability API calls.