Skip to main content
Unifystays returns structured errors with HTTP status codes. Every response includes an X-Request-Id header.
Include this request ID when reporting an issue.

Common Status Codes

Retry Guidance

  • Safe to retry: GET endpoints and POST /hotels/book with the same Idempotency-Key and identical request body.
  • Use caution: POST /hotels/prebook, because supplier availability can change.
  • Do not create a new booking retry key unless the user intentionally starts a new booking attempt.
For 429 and transient 500 responses, delay the retry and increase the delay between consecutive attempts. Do not retry a failed validation request until you have corrected the input.

Expired Tokens

Room booking_token and prebooking IDs are short lived. If a token expires, restart from room availability or search.

Room Allocation and Prebook Errors

A room without a safe catalogue match is not an error. AMBIGUOUS, UNMAPPED, and CONFLICT mapping statuses have unifystays_room: null; all are supported bookable states when the option and allocation IDs are present. Render the room from provider_room instead of hiding the option.

Supplier Operation Errors

Supplier-native error strings are retained privately for support and are not a stable customer contract. Use the normalized Unifystays code and retryable value instead. For an uncertain booking-creation result, Unifystays keeps the booking in PROCESSING and performs supplier status reconciliation. Do not create a new booking or change the idempotency key. For an uncertain cancellation result, the booking remains CANCELLATION_PENDING until the supplier order record confirms its state.

Search Refreshes

  • Poll GET /hotels/search/{searchId}/prices every 2 seconds only while the customer is viewing a search result page.
  • Stop polling when the refresh status is COMPLETE or EXPIRED.
  • Use refresh_ids to prioritize hotel cards currently visible to the customer.
See Caching Strategy for cache lifetime and request volume guidance.