🔧 Introduction

Rebook is a service integrated into the Ratefox product suite. Rebook monitors hotel bookings post-confirmation while they remain refundable. It automatically detects rate decreases and executes rebookings when lower prices emerge, optimizing affiliates' margins without customer intervention.

When Rebook is activated and tailored to a Ratefox client, the client gains enhanced capabilities through the extended Ratefox API to manage and analyze the rebooking process for each booking.

🛠️ Endpoint Reference

A comprehensive description of all Ratefox API endpoints can be found on the Implementation Guide - Ratefox V2 page.

In this section, we will explore the application of the API in the context of Rebook, emphasizing key points.

✅ POST /hotels/ratefox

Ratefox endpoint allows to book the specified hotel room at a better price. Rebook monitoring is launched automatically for each Ratefox booking if it meets rebooking criteria:

❗️

General rebooking criteria:

To be taken under Rebook monitoring a booking must meet the following criteria:

• single room booking;
• at least 1 day before check-in;
• at least 1 day before free cancellation period deadline.

In case you want to exclude a booking from Rebook monitoring set "ExcludeFromRebooker": true in Ratefox request.

If Ratefox successfully created a booking then in Ratefox response "IsRebookCandidate" = true indicates Rebook is launched for the booked segment, "IsRebookCandidate" = false indicates the segment doesn't meet rebooking criteria and Rebook won't monitor it.

Full Ratefox endpoint description - Click here.

✅ POST /hotels/rebook

Rebook endpoint allows to launch Rebook monitoring for a booking created on a client side. Full booking description should be provided in the API request the same way as it is done for Ratefox endpoint with one addition:

• CustomBookingReference is mandatory for Rebook request and must be unique among all successful Rebook requests. Best practice is to use as a CustomBookingReference the unique booking identifier from client system.

CustomBookingReference will be sent to the client with a notification when Rebook find and book the better alternative ensuring the ability to update booking data in the client's system.

❗️

Extremely important:

If client-side created booking was rebooked the client is responsible for cancelling original booking with its supplier. This is required only after first rebooking is made, for subsequent rebookings previous bookings will be canceled by Rebook (as they are created by Rebook).

For each Rebook request an order (booking) with "Ev" status is created to represent the client-side booking in Ratefox system and to serve it within the same Rebook flow which is used for Ratefox bookings. The OrderID and SegmentId of this internal Ratefox booking are provided in Rebook response. These identifiers can be used to access the endpoints listed below.

In case the booking from Rebook request doesn't meet General rebooking criteria (see above in highlighted block) the request is rejected and an error is returned in the response.

Full Rebook endpoint description - Click here.

✅ POST /hotels/excludefromrebooker/{orderId}

If a booking is under Rebook monitoring and you need to exclude it from Rebook process you should call excludefromrebooker endpoint with OrderId of the booking. Both Ratefox bookings and client-side bookings can be excluded.

👍

Notes and Tips :

• OrderId is returned in Ratefox API response for Ratefox booking and in Rebook API response for client-side booking;
• Only the booking for which Rebook was successfully launched can be excluded from Rebook monitoring. Otherwise excludefromrebooker endpoint will return an error.
• Use OrderData endpoint to check if a booking is under Rebook monitoring.

Full Excludefromrebooker endpoint description - Click here.

✅ POST /hotels/orderdata/{orderId}

Orderdata endpoint provides the following information:

• current booking parameters taken into account all applied rebookings;

• the history of rebooked bookings including the initial one.

  

If Rebook is operating in evaluation mode and better alternative is found then:

• no parameters are changed in current booking description;
• found alternative parameters and possible profit increase are fixed in the history of rebookings for the initial booking. For this element of history "Status": "Ev".

If Rebook is operating in live mode and better alternative is found and booked then:

• the following parameters are updated in current booking description:
  • SupplierId;
  • SupplierName;
  • ContractId;
  • FinalPrice;
  • FinalPriceInClientCurrency;
  • Revenue;
  • RevenueInClientCurrency;
  • TotalRevenue;
  • TotalRevenueInClientCurrency;
• found alternative parameters and profit increase are fixed in the history of rebookings for the initial booking. For this element of history "Status": "OK";
• previous booking is cancelled if it was made on Ratefox side, for its element in history "Status" will be changed to "CX".

Regardless work mode of Rebook the booking in its initial state also is added to the history when the first better alternative is found (evaluation mode) or booked (live mode). For the element of history representing the initial booking state "Initiator": "Ratefox". For the elements of history representing rebookings "Initiator": "Rebooker".

👍

Notes and Tips :

• OrderId is returned in Ratefox API response for Ratefox booking and in Rebook API response for client-side booking;
• If Rebook is operating in live mode for evaluation Ratefox bookings it will work in evaluation mode. Exeption: evaluation bookings created by Rebook API request. For these bookings Rebook will work in live mode producing real rebookings;
• If a Ratefox client starts using Rebook in evaluation mode and then switches to live mode Rebook will continue to monitor the bookings for which it was already launched. Thus in the history of rebookings for one booking both elements with "EV" status (created when Rebook was in evaluation mode) and elements withCX" or "OK" statuses (created after Rebook was switched to live) can be presented;
• Rebook work mode for the client is set by Ratefox support team.

The OrderData response includes specific parameters that are relevant only if Rebook is enabled for the client:

• IsRebookCandidate - true indicates Rebook monitors the booking for better rates, false the Rebook monitoring was stopped or was never launched for the booking (the booking is excluded from Rebook monitoring);
• IsProfitRequirementMet - is relevant for Ratefox bookings if fallback to zero profit is allowed for Ratefox requests (this option is set for the client by Ratefox team). True if initial Ratefox booking generated Revenue greater than threshold from client settings. False if Revenue was less than threshold from client settings (in this case booking was created without expected profit as a start point for Rebook).
• TotalRevenue - total revenue generated by Ratefox (if booking is created by Ratefox request) and all live rebookings (evaluation rebookings are not taken into account);
• TotalRevenueInClientCurrency - total revenue in client currency;
• History - array of objects representing initial booking state and all its rebookings.

Full Orderdata endpoint description - Click here.