Skip to content

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.comSign 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 (APPROVEDBOOKED)

  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.