Reservation Recovery API overview

Use the Reservation Recovery API to recover missed reservations.

What are missed reservations?

Missed reservations are those messages (including confirmations, modifications, and cancellations) that were not:

Pulled within 30 minutes (using the B.XML endpoint). For example, you did not retrieve the reservations within the timeout period.
Pulled and acknowledged within the 30-minute timeout period (using the OTA XML endpoints). For example, you did not acknowledge a reservation by calling the POST OTA_HotelResNotifRS endpoint within the timeout period.

Active rejections are currently not supported

Reservation messages that were actively rejected using the POST OTA_HotelResNotifRS endpoint with an <Error> tag response are currently not returned using the missed-reservations endpoint.

You must use this API along with the Reservations API (both OTA XML and B.XML endpoints). The following sections explain when to use this API and provide more information on the reservation recovery process.

The feature 'Enable Reservation Recovery API' is deactivated by default

To start implementing the Reservations Recovery API, contact the Connectivity support team who will activate the feature for you.

With the feature activated, the timeout period to trigger the fallback email changes from 30 minutes to 24 hours with the exception of reservations whose check-in date is within the next 48 hours. For such reservations, the fallback email is triggered immediately after the 30-minute timeout period.

With the feature deactivated, the property will still receive fallback emails for reservations missed after the 30-minute timeout period.

If reservations messages whose checkin date is within the next 48 hours are not pulled/acknowledged in time, then the fallback email is triggered immediately after the 30-minute timeout period irrespective of the feature setting.

Once the fallback email is triggered, reservations messages no longer stay in the missed reservations queue.

Deactivation of the usage of the `last_change` query parameter while retrieving reservation messages

Because Reservations Recovery API helps you retrieve missed reservations messages, you no longer need to use the last_change query parameter while retrieving reservations messages using either OTA or B.XML endpoints.

Therefore, after you enable the feature 'Enable Reservation Recovery API', continuing to use the last_change query parameter will return the following error response: invalid last_change value - an ISO 8601 date and time (yyyy-mm-dd hh:mm:ss), at most 30 minutes ago because you are a part of the Reservation Recovery program.

Why use the Reservation Recovery API?

The Reservations Recovery API provides a longer timeout window (from 30 minutes to 24 hours) for you to process the missed reservations data before the fallback mechanism is triggered for those reservations. You could get better performance, and more up-to-date and accurate data. This in turn enables you to improve your recovery and set up better follow-ups with your properties.

Reservation Recovery API process

This section illustrates the reservations recovery process flow when using both OTA XML and B.XML Reservations API endpoints.

OTA reservation recovery process

The following 2 process flow diagrams show the steps to recover missed reservations that are new, modified, or cancelled.

Click on the diagram to see it in full screen. To return to the topic, click the browser's back button.



1. Provider fails to acknowledge a new reservation within the first 30-minute window by calling the `POST OTA_HotelResNotif` endpoint. 2. Booking.com moves the missed reservations to the missed reservations queue. 3. Provider calls the `GET /reservations-flow-control/missed-reservations` endpoint after the 30-minute timeout period but within the 24-hour deadline. 4. Booking.com returns reservation ID(s) of any missed reservations with `reference_type=confirmation_to_hotel`. 5. Provider calls the `GET OTA_HotelResNotif` endpoint with the specific reservation ID and property ID. 6. Provider integrates booking into their system and updates inventory. 7. Provider calls the `POST OTA_HotelResNotif` endpoint within the timeout period. 8. Booking.com returns a successful `OTA_HotelResNotifRS` message. Note: If the provider doesn't retrieve the missed reservation messages and acknowledge the reservations within the 24-hour timeout window, then Booking.com sends a fallback email directly to the property with the reservation details.		1. Provider fails to acknowledge a modified/cancelled reservation within the first 30-minute window by calling the `POST OTA_HotelResModifyNotif` endpoint. 2. Booking.com moves the missed reservations to the missed reservations queue. 3. Provider calls the `GET /reservations-flow-control/missed-reservations` endpoint after the 30-minute timeout period but before the 24-hour deadline. 4. Booking.com returns reservation ID(s) of any missed reservations with `reference_type=modification_to_hotel` or `cancellation_to_hotel`. 5. Provider calls the `GET OTA_HotelResModifyNotif` endpoint with the specific reservation ID and property ID. 6. Provider integrates booking into their system and updates inventory. 7. Provider calls the `POST OTA_HotelResModifyNotif` endpoint within the timeout period. 8. Booking.com returns a successful `OTA_HotelResModifyNotifRS` message. Note: If the provider doesn't retrieve the missed reservation messages and acknowledge the reservations within the 24-hour timeout window, then Booking.com sends a fallback email directly to the property with the reservation details.

B.XML reservation recovery process



1. Provider fails to retrieve a new reservation within the first 30-minute window by calling the `POST reservations` endpoint. 2. Booking.com moves the missed reservations to the missed reservations queue. 3. Provider calls the `GET /reservations-flow-control/missed-reservations` endpoint after the 30-minute timeout period but within the 24-hour deadline. 3. Booking.com returns reservation ID(s) of any missed reservations. 4. Provider calls the `POST reservations` endpoint with the specific reservation ID and property ID. 5. Booking.com returns the reservations details. 6. Provider integrates booking into their system and updates inventory. 7. After a delay, call the `/reservations` endpoint again. Note: If the provider doesn't retrieve the missed reservation messages within the 24-hour timeout window, then Booking.com sends a fallback email directly to the property with the reservation details.

1. Provider fails to retrieve a new reservation within the first 30-minute window by calling the POST reservations endpoint.
2. Booking.com moves the missed reservations to the missed reservations queue.
3. Provider calls the GET /reservations-flow-control/missed-reservations endpoint after the 30-minute timeout period but within the 24-hour deadline.
3. Booking.com returns reservation ID(s) of any missed reservations.
4. Provider calls the POST reservations endpoint with the specific reservation ID and property ID.
5. Booking.com returns the reservations details.
6. Provider integrates booking into their system and updates inventory.
7. After a delay, call the /reservations endpoint again.
Note: If the provider doesn't retrieve the missed reservation messages within the 24-hour timeout window, then Booking.com sends a fallback email directly to the property with the reservation details.

Quick Actions

→ To retrieve missed reservations, see Retrieving missed reservations