What information can I get from the Fallback CSV file?

At Booking.com, we’re committed to reaching a 100% success rate in our reservation calls with all our Connectivity Partners.

To do that, we want to make sure that all reservations and changes to reservations are continuously synced between both our platforms. By having all our systems synced with the right reservation data, we can avoid misunderstandings on the part of properties and guests.

Our fallback metric measures delivery failures for reservation messages. We can then share this data with you via the Provider Portal. 

Since fallbacks can be caused by a range of different factors, we believe that having access to more data can help you analyse and tackle the root causes more effectively, leading to a reduction in fallbacks.

In the Provider Portal, you can now download a csv file that provides you with detailed fallback data for any chosen period. In this data file, you’ll see the following columns:

1. Reservation_ID: this column gives you a list of reservation IDs that have experienced a delivery failure.
2. Property_ID: this column gives you the Booking.com property ID associated with a fallback reservation message.
3. Property_name: this column gives you the Booking.com property name associated with a fallback reservation message.
4. Checkin_date: this column gives you the check-in date associated with a fallback reservation.
5. Reservation_status: this column shows the technical message status of the fallback message. It can contain three values:
1. active = not cancelled and available in the API. You can pull again using the ‘id’ parameter to retrieve this reservation message.
2. cancelled = cancelled. You can pull again using the ‘id’ parameter to retrieve this reservation message.
3. archived = no longer available in the API.
6. Last_communicated_by: this column contains one of the following two values:
1. Xml = there was a successful API delivery after the fallback. We sometimes try to resend reservation messages after a failure.
2. Email = the message delivery via API failed and did not subsequently recover.
7. Fallback_timestamp: this column shows the timestamp of the API failure, which refers to the time when we sent the fallback email.
8. Message_type: this column indicates the type of reservation message, which could be either a confirmation, modification or a cancellation message.
9. Fallback_reason: this column gives an overall indication of why the message delivery failed: 

1. Refused = the provider has rejected the reservation message.
2. Missed_deadline = the provider has tried to retrieve the reservation message, but after the retrieval deadline had passed.
3. Missed_reservation = the provider has not retrieved the reservation message at all.
4. Missed_confirmation = the provider has retrieved the reservation message but has not confirmed a successful delivery. It's only possible to get this Fallback_reason if you work with the OTA_HotelResNotif and OTA_HotelResModifyNotif endpoints.

Please note that some data may be missing or redacted. For example, in case the fallback has not yet been covered by our automatic analysis, or if the connection to the accommodation has been terminated. Typically, all fallbacks should appear after a minute, and complete analysis should appear within a few days.