1. Search
Search establishes destination, dates, occupancy, nationality and other shopping context. The result should contain enough summary data to compare hotels while retaining identifiers needed to retrieve bookable room options.
2. Retrieve rates and review the selection
Room and rate retrieval exposes policies and option details. Review or prebook then checks that the exact option remains available at the expected price before checkout commits.
3. Create the booking safely
Booking is a side-effecting operation. Use a client-generated idempotency key where supported, persist the attempt before retrying and distinguish a confirmed failure from an unknown outcome that requires status reconciliation.
4. Confirm status and cancel
A booking response should not be treated as the only source of truth. Persist provider references and booking events, support status retrieval, and apply the supplier-returned cancellation policy rather than a generic rule.
Primary sources
External technical details referenced on this page are linked to their original publisher.
Frequently asked questions
Why is review or prebook required?+
Hotel rates and availability can change between search and checkout. Review confirms the selected option immediately before booking.
What if the booking request times out?+
Do not blindly create another reservation. Reconcile using the idempotency key, internal attempt record and supplier booking-status operation.
Where does payment happen?+
Payment and settlement vary by product and supplier contract. The booking API should clearly state whether it expects payment confirmation, a guarantee or only traveller details.