Hotel retries and idempotency

You distinguish a repeat read from a new purchase. Reusing a booking ID or prebook key lets you recover stored state; a new key can create a second booking.

Operation	How you recover
Search, offers, places, content, capabilities or booking weather	You can repeat a failed read with bounded backoff. Inventory, prices and offer references may change.
Cancellation quote	You can repeat this read with bounded backoff. Each request obtains fresh supplier data; fees can change. After 409, read the booking before requesting another quote.
Prebook	You repeat the original request with the same x-idempotency-key, organization and user. You receive the existing booking if it was stored.
Book	You read GET /bookings/{id} after a timeout, conflict or unknown result. You never start a replacement purchase while this booking is unresolved.
Cancel	You read the booking and its attempts. A repeated cancel request reuses an active attempt and can resume a failed workflow.

Reuse a prebook key deliberately

You choose one key of at most 200 characters per intended booking and retain it before sending prebook. Reusing it returns the stored booking; it does not update guests, replace the offer or compare the new body with the original body. A syntactically valid repeat can return the booking even after the original offer expires.

You use a new key only for a new intended booking, after resolving the previous outcome. Your reference_id does not deduplicate requests. A repeated key does not reissue a Payment SDK token; contact support if you lost the original token and cannot finish that payment flow.

Recover a payment SDK checkout

You retain the booking ID and protect the token returned by a fresh SDK prebook; never log the token or put it in a URL. A missing token on a repeated request does not mean that the original prebook or payment failed.

Interrupted step	Your next action
The prebook response was lost	Repeat the original prebook with the same key to recover the booking. If its token is unavailable, contact support before replacing the checkout.
The token was lost before payment	Contact support with the booking ID; neither a booking read nor repeating prebook reissues it.
Payment was submitted but its outcome is unknown	Keep the same booking and resolve that payment with support; do not start another payment because the browser stopped responding.
The SDK explicitly refused payment	Resolve the original payment outcome before starting a new intended booking with a new key, then review the new prebook price and terms.
Book timed out after authorization	Read the same booking; authorization does not establish whether the supplier confirmed the stay.

Recover completion without another purchase

You keep the booking ID before calling book. A repeated book request for a previously confirmed booking returns its stored state, which can now be canceled. Other requests must still meet the current booking and payment conditions.

You do not automatically retry a purchase based on an HTTP status alone. result_unknown, an interrupted connection or a generic server error can mean the supplier acted before the response was lost. Read the existing booking and contact support with its ID and the service request ID if it stays unresolved. Reading a booking returns stored state; it does not force a supplier refresh.

Poll stored state and use webhooks

You use GET /bookings/{id} to observe stored state after an interrupted mutation. Poll sequentially with a bounded retry budget and increasing delays; for example, wait 2, 4, 8, then up to 15 seconds between reads with jitter. These intervals are integration guidance, not a completion-time guarantee. A read does not restart a workflow or force a supplier refresh.

You stop automatic polling when the status permits your next action, or when your retry budget is exhausted. For CONFIRMED, present the reservation; for FAILED or EXPIRED, resolve any payment uncertainty before starting a new booking. For CANCELED, inspect the cancellation and refund intent. For PARTIALLY_CANCELED, inspect every room and the attempt history. READY_FOR_COMPLETE requires your payment and book steps; polling alone does not complete it.

You keep unresolved bookings visible for support rather than changing them to failed locally. Retain the booking ID, the original prebook key and any request IDs. A client timeout or polling deadline is not evidence that a supplier refused the operation.

You can use partner webhooks to reduce polling. Verify the signature over the raw body before parsing, deduplicate by the signed event ID, and read the booking when you need its current state. Events can be delayed or delivered out of order; do not overwrite a newer state solely because a notification arrived later. A booking event does not establish refund settlement. Follow Hotel webhooks for registration, signature verification and delivery recovery.

Resume cancellation

You request cancellation for all remaining rooms. After a cancellation dispatch is recorded, recovery retrieves the supplier outcome instead of blindly sending the mutation again. Partial cancellation can leave live rooms and a refund for rooms already released.

You allow an earlier attempt's refund processing to finish or resume before requesting another attempt for remaining rooms. A null refund requires investigation; retrying the cancellation does not turn an unknown fee into zero.