The hotel prebook step: what it does and why it matters

The hotel prebook step is a check your booking system makes with the hotel supplier's API just before the final booking. It confirms that the chosen room and rate are still available, and returns the current price and cancellation policy. If anything has changed since the search, prebook is where you find out, before the customer pays and before a booking is attempted. It is the hotel equivalent of a flight price check, and skipping it is a common cause of failed bookings and unhappy customers.

An API (application programming interface) is how your system exchanges data with a supplier's system. Hotel supplier APIs usually offer separate steps for searching, prebooking and booking. This guide explains what happens at the prebook step and how to handle its results. If you are building a hotel or travel booking platform, our OTA platform service page explains how we work.

Where the hotel prebook API call sits in the booking flow

A typical hotel booking journey through a supplier API looks like this:

1. Search. The customer searches for a destination and dates. The API returns hotels with available rooms and rates.
2. Choose a room. The customer selects a hotel, a room type and a rate, such as room only or with breakfast, refundable or non-refundable.
3. Prebook. Your system asks the supplier to confirm this exact rate. The supplier returns the confirmed price, the cancellation policy and often a token or reference to use in the next step.
4. Guest details and payment. The customer enters guest names and contact details and pays, or the payment is authorised.
5. Book. Your system sends the booking request with the prebook reference. The supplier confirms the booking and returns a booking reference.
6. Voucher. Your system sends the customer a confirmation and a hotel voucher.

The prebook step usually happens when the customer chooses a room, or just before they pay. Some teams run it at both points if the customer takes a long time on the details page.

Flights have a similar check before booking, and our guide to flight booking flow design shows where it fits among the other screens.

What the supplier checks during prebook

The exact checks vary by supplier, but prebook typically confirms:

• Availability. That the room type is still available for the dates and number of guests.
• Price. The current total, which may differ from the search result because of updated rates, taxes or fees.
• Rate conditions. Board type, such as breakfast included, and any rate restrictions.
• Cancellation policy. The deadlines and fees that apply if the booking is cancelled. This can change between search and prebook.
• Taxes and local charges. Some fees are included in the price; others are paid at the hotel. Prebook often gives clearer detail than search.
• Booking requirements. Information the supplier needs for the final booking, such as how many guest names are required per room.

Search results are designed to be fast across many hotels, so they are sometimes less precise. Prebook focuses on one rate and gives the answer you should rely on.

Why cancellation policies deserve extra care

Cancellation terms are easy to overlook in a booking flow, but they are what customers remember when plans change. A rate that was refundable at search can become non-refundable by the time of prebook, or its free cancellation deadline can move. Show the policy returned by prebook in plain words, including the deadline in a clear time zone, and store it with the booking. When a customer later asks to cancel, your team and your refund calculation should use exactly that policy, not the one shown at search or a newer one from the supplier.

Handling a changed rate or cancellation policy

When prebook returns something different from the search, the customer must know before they commit.

1. Compare every important field. Check the total price, board type and cancellation policy against what the customer saw.
2. Show changes clearly. Display the old and new price side by side, and highlight any change in cancellation terms. A policy that was free to cancel and is now non-refundable is a significant change, even if the price is the same.
3. Ask the customer to confirm. Never continue to booking with a higher price or stricter terms without the customer agreeing.
4. Offer alternatives. If the rate is no longer available, return the customer to the hotel's other rates or similar hotels, keeping their search details.
5. Treat price drops honestly. If the price went down, show the lower price.
6. Save what was agreed. Store the prebook result and the customer's confirmation with the booking record. Refunds and support questions later should follow what the customer accepted.

Your admin panel should show the search price, the prebook result and the final booking side by side. This makes customer service and supplier disputes much easier to resolve.

How long a prebook result stays valid

A prebook result is not permanent. Suppliers usually treat it as valid for a limited time, after which the booking request may be rejected or the rate may need to be checked again. The exact period, and whether it is stated in the response, depends on the supplier's documentation.

1. Read the supplier's rules. Find out how long a prebook remains valid and whether the response includes an expiry time.
2. Store the time of the prebook with its result.
3. Check again when needed. If the customer takes longer than the valid period on the details or payment page, run prebook again before booking.
4. Show a clear message if the price needs rechecking, rather than letting the booking fail at the last step.
5. Keep the flow short. A shorter details and payment page reduces how often prebook results expire.

Do not assume that prebook reserves the room. Check your supplier's documentation: in many APIs, prebook confirms the rate at that moment, and the room is only secured by the final booking request.

Taking payment around the prebook step

The order of prebook, payment and booking matters, because the customer's money should only be taken for a booking that can be confirmed.

1. Prebook before payment. The customer should pay the confirmed price, not a search price that may be out of date.
2. Authorise, then capture. Where your payment gateway supports it, reserve the amount on the customer's card first, book with the supplier, then capture the payment only when the booking is confirmed.
3. Release the authorisation if the booking fails. The customer is not charged for a booking that did not happen.
4. Handle unclear outcomes carefully. If the booking request times out, do not assume it failed. Check the booking status with the supplier before releasing the payment or trying again, to avoid double bookings.
5. Keep the payment and booking records separate, each with its own status, so your team can see exactly what happened.

These rules protect both your customers and your business. Our guide on why travel bookings fail at confirmation explains how to handle failed and unclear bookings in more detail, and our guide to why flight prices change between search and booking covers the same problem for flights.

Once the booking is confirmed, the supplier data is turned into a voucher, and our guide on how e-tickets and vouchers are issued covers that final step.

Summary

• Prebook confirms that a chosen hotel rate is still available and returns the current price and cancellation policy.
• It sits between choosing a room and the final booking, and may need repeating if the customer takes a long time.
• Show any change in price or cancellation terms clearly and ask the customer to confirm.
• Prebook results expire, and you should not assume they reserve the room.
• Prebook before payment, authorise before booking and capture only when the booking is confirmed.

A reliable prebook step is one of the simplest ways to reduce failed hotel bookings and customer complaints. If you're building or improving a hotel booking platform, you can tell us about it here.