The hotel price changed before booking. What should your booking engine do?
A reliable hotel API price recheck is not simply a second request for a number. It protects the meaning of the offer the customer accepted: room, occupancy, board basis, cancellation policy, taxes, currency, payment terms, and availability.
An agent finds a hotel, shares a quotation, and gets approval from the traveler. Ten minutes later, the booking request comes back with a different amount, or an error. Which price is correct? More importantly, what should the booking engine do next?
In Amadeus' September 2026 research of more than 750 travel sellers, 94% rated rate parity highly important; 63% said they would book away from a property when they perceived inconsistent pricing. Those are reported opinions about parity, not measured losses from search-to-book repricing. But they underscore how seriously travel sellers take pricing consistency.
A search result is not a confirmed reservation
The same hotel offer passes through several different moments:
- Search: A supplier returns a rate and availability at a particular moment.
- Quote: The agency presents an offer, often after applying its own commercial rules.
- Validate: The selected supplier rate is checked again when the customer is ready to proceed, where the supplier workflow requires it.
- Book: A reservation request is submitted and its actual status is established.
Between these moments, inventory can move, a token can expire, or commercial terms can change. The platform should distinguish an offer shown to a customer from an offer currently acceptable for booking.
A useful internal offer record holds more than totalPrice:
| Field | Why it matters |
|---|---|
| Supplier and original rate identifiers | Reconnects the offer to its source and booking conditions |
| Hotel, room, occupancy and dates | Prevents comparisons between non-equivalent stays |
| Meal plan and cancellation terms | Can change the value of a superficially cheaper rate |
| Currency, taxes and fees | Determines what is included, excluded or payable at property |
| Booking token or link and retrieval time | Helps enforce the supplier's lifecycle |
| Current validation and booking state | Prevents expired offers being treated as confirmed products |
One Offer, Four Validation Points
- Search
A rate and availability, at one moment.
- Quote
The offer the agency actually presents.
- Validate
The supplier's own price check, when its rules require one.
- Book
A reservation whose status is known.
Off the main path
- Changed termsShow what changed. Ask for a decision before substituting a different offer.
- Uncertain bookingA timeout is not a failure. Retrieve the attempt before sending another reservation.
Search, quotation, supplier-specific price validation, and booking are four checks of one offer. Changed terms, and a booking whose outcome is not yet known, leave that path and are handled on their own.
Why two prices may not describe the same offer
Suppose two suppliers return the same property and dates. One advertises a lower total, but the other includes breakfast and free cancellation. A basic sorting algorithm declares a winner; the customer may not agree.
Hotel matching and room equivalence are separate problems. Mapping two supplier hotel records to one property does not prove their room categories, occupancy conditions or board plans match. A defensible comparison can say “not comparable” rather than inventing equivalence.
Taxes make the comparison harder. HEDNA's August 2026 briefing explores how tax type, jurisdiction, amount and remittance details can lose meaning between hotel and distribution systems. An integration should preserve that information, not flatten every charge into an unexplained total.
A simple rule helps: compare the complete commercial offer, not just the number in the price column.
A hotel API price recheck must follow the supplier's rules
There is no universal “call /recheck before every booking” standard. Each supplier defines what makes an offer bookable.
For example, Hotelbeds' Booking API workflow distinguishes RECHECK rates, which require CheckRate before booking, from BOOKABLE rates that can proceed directly under the documented workflow. That distinction belongs in the integration contract, not in a generic frontend assumption.
Expedia Rapid's error and recovery documentation describes price mismatches and expired booking links separately. In a price-mismatch recovery, a fresh Price Check may be necessary to obtain the current booking link. Merely changing the displayed amount is not enough.
A supplier adapter should therefore own supplier-specific rules for token expiry, price validation, availability failures, booking submissions and retrieval. The business layer can then expose consistent states to the sales team without pretending every API behaves identically.
When the rate changes, show what changed
Consider this illustrative scenario:
An agency quotes a three-night, breakfast-inclusive, refundable room. During validation, it finds a slightly cheaper room-only, non-refundable rate. If the interface updates only the total, the customer may unknowingly accept a worse product.
A safe flow checks:
- Has the amount changed, and by how much?
- Has cancellation flexibility changed?
- Is breakfast or another service still included?
- Are taxes, property-payable fees and payment timing unchanged?
- Is the original room still available?
- Does the customer's approval still cover the new terms?
If a material term changes, the system should request an explicit decision or offer an alternative, not silently substitute it. The agency also needs a written policy for who may absorb a small rate increase and what requires customer reapproval.
A booking timeout is a different problem from a price mismatch
This is the dangerous edge case. A booking request times out. The user sees no confirmation. Does that mean the reservation failed?
Not necessarily. Expedia's documentation explains that a timeout or 5xx response can occur after a reservation was created and advises checking the booking via the supplier's retrieval process. Sending another booking request blindly can create duplicate financial exposure where the supplier's contract does not guarantee safe idempotent retries.
Treat the outcomes separately:
- Offer rejected or price changed: validate the new offer and request approval where necessary.
- Room unavailable: show an accurate unavailability state and alternatives.
- Booking status unknown: retrieve and reconcile the existing attempt before considering a new reservation.
- Booking confirmed: store the supplier confirmation and advance the customer workflow.
In other words, a price-recheck engine and a reservation-recovery engine solve related, but different, problems.
Measure where pricing trust breaks
A team can improve only what it can locate. Track search-to-validation mismatch rates, validation-to-booking mismatches, expired-token errors, unresolved booking attempts, average recovery time and the share of revised offers that customers accept.
Break results down by supplier and operation. A single overall error rate can hide one problematic rate type or one slow supplier. Also preserve a trace of what the customer originally accepted, using privacy-conscious logging and redaction.
The practical takeaway
The cheapest hotel result is not necessarily the best offer. A successful API response is not necessarily a confirmed booking. And a second price request does not guarantee commercial certainty forever.
Reliable hotel booking software manages the entire offer lifecycle: source, comparison, validation, consent, reservation and recovery.
If your team regularly investigates rate mismatches by hand, start by mapping the search-to-booking flow, identifying the supplier-specific validation requirements and examining the exceptions that customer support handles today. That often reveals the engineering work that matters most.
For teams working on booking systems and supplier connections, WebbingHUB Travel focuses on the integration layer and the operational realities behind hotel distribution.
Sources and further reading
- Amadeus, Global travel sellers and rate parity (29 September 2026)Survey attitudes, not measured booking-loss outcomes.
- Hotelbeds, Booking API workflowSupplier-specific recheck logic.
- Expedia Group, Rapid API common error responsesPrice mismatches, links, booking status and recovery.
- HEDNA, Taxes, Fees & the Distribution Gap (August 2026)Tax and fee data across distribution systems.