Skip to main content
POST
Call this endpoint after the customer selects a hotel. It is the second step of the flow: Search → Rooms → Prebook → Book. Send the same dates, occupancy and nationality used for hotel search. Unifystays calls the active suppliers in parallel and normalizes their room options. The POST returns quickly. It answers with the rooms Unifystays already knows for this hotel and a stream_id / sse_stream_url. The live supplier offers then arrive on that stream as Server-Sent Events, one provider_options event per supplier batch, and a final done event. Read the stream with Stream Room Updates. Each streamed offer carries two identifiers you need later:
  • booking_token: identifies the whole offer. You send it to Prebook.
  • room_allocation_id: identifies one room slot of the offer.
1

POST the stay

Send dates, nationality and the occupancy of every room. Keep data.unifystays_rooms and open data.sse_stream_url immediately.
2

Read the stream

Add family objects and offers as provider_options events arrive. Stop at done.
3

Show room cards

Draw one card per room family with the offers under it (see Render Room Cards).
4

Prebook the chosen offer

Send its booking_token unchanged to Prebook.

Request Example

Request Fields

Optional header X-Unifystays-Currency (an ISO 4217 code such as EUR) sets the display currency for this request. Without it the response uses your organization’s display currency, which is USD unless configured. See Display currency. If the customer changes the hotel, dates, nationality, number of rooms, or any room’s occupancy, request room options again. Tokens from the old request must not be reused. Errors: 400 for an invalid body (for example check_in in the past, or check_out not after check_in), 404 when the hotel does not exist. The body is checked when you POST; supplier problems are reported later on the stream, not as an HTTP error.

Initial Response Example

The POST response is intentionally fast. data.options is initially empty; connect to data.sse_stream_url to receive live provider_options events. This example is for a hotel that was searched before. On a hotel’s first search unifystays_rooms is [].

Use the Response

The initial response contains the rooms already known for this hotel and a stream_id with sse_stream_url. Live supplier options are delivered progressively through the stream. Every streamed bookable option includes a short signed booking_token required by Prebook a Room.
Room grouping never changes what is booked. Every offer is the supplier’s own offer: booking_token and room_allocation_id identify it, whatever room it is shown under.

Render Room Cards

Offers from different suppliers for the same physical room are grouped in one family object, split into variants by bed type. Draw one card per family:
  • Header: the family’s name and details (photos, size, description, amenities) labelled with details.source, for example “Photos & details: TripJack”.
  • Variants: show each variant’s beds, bedrooms, max_guests and smoking only from the variant object in variants[]; a null value is unknown.
  • Rows: one per offer, with price, meal plan and cancellation from the offer, under the variant its slot’s unifystays_room_id names. Offers listed under bed_assignment.suppliers (their slot id is the family id) go under the label Bed type assigned by the hotel. Each offer row always shows its own provider_room beds and maximum guests.
What to put on each part of the card:

Display currency

Every offer’s pricing carries display_currency and display_ledger: the supplier’s native_ledger lines converted to the display currency, which is your organization’s setting or the X-Unifystays-Currency header. Read display_currency instead of assuming it. native_ledger stays the authoritative amount owed. A display_* value is null when no exchange rate is available for the currency; it is never a made-up zero. Display amounts are converted with the current rate and are for showing only. The supplier charges in the native currency. Room ids:
  • unifystays_room_id is for display and grouping only. Book with booking_token and room_allocation_id.
  • A tmp_ id is valid for this search only. Do not store it.
  • A built room id may be retired later, when two rooms turn out to be the same room. Do not keep room ids as long-lived keys.
  • A later provider_options event may send a family again with different variants, bed_assignment or details: replace your copy.
Client logic:
For a multi-room search the card key is offer_family_id ?? offer_id and the header lists each slot’s family. An offer with offer_family_id: null contains a tmp_ room, so a multi-room offer with a tmp_ room gets its own card.
  • Keep the selected option’s booking_token only for the immediate prebook step; it is time-sensitive.
  • Connect to Stream Room Updates to obtain the bookable options and their identifiers.
  • Request fresh room options if the stay dates, guest mix, nationality, or selected hotel changes.
Do not cache room options or reuse their booking tokens as a checkout guarantee. Supplier-backed availability and price can change.
The OpenAPI section below provides the complete request body and response fields, including room options and stream identifiers.

Authorizations

x-api-key
string
header
required

Environment-specific API key created in the Unifystays portal

Headers

X-Unifystays-Contract-Version
enum<string>
default:2

Hotel API contract version. Optional: 2 is the current version and the default.

Available options:
2
X-Unifystays-Currency
string

ISO 4217 currency for display amounts (display_ledger, display_amount, commercial_display). Optional: defaults to your organization's display currency, USD unless configured. Read pricing.display_currency in the response.

Required string length: 3
Example:

"EUR"

Path Parameters

hotel_id
string
required

Unifystays hotel ID from hotel search or destination autocomplete (numeric string).

Example:

"123456"

Body

application/json
check_in
string
required

Check-in date (YYYY-MM-DD). Today or later. Use the same date as the hotel search.

Example:

"2026-07-01"

check_out
string
required

Check-out date (YYYY-MM-DD). Must be after check_in. Use the same date as the hotel search.

Example:

"2026-07-04"

rooms
object[]
required

One entry per room the guest needs (1 to 8). Order is preserved: slot N of every offer answers rooms[N]. Each room has adults and child_ages (use [] for no children).

Required array length: 1 - 8 elements
Example:
residency
string

Guest country of residence, ISO 3166-1 alpha-2 (for example IN). Suppliers use it for residency-restricted rates. Defaults to nationality when omitted. When both are omitted, IN is used, so always send at least one.

Example:

"IN"

nationality
string

Guest nationality, ISO 3166-1 alpha-2 (for example IN). Suppliers use it for market eligibility, pricing and booking rules. Defaults to residency when omitted. When both are omitted, IN is used, so always send at least one.

Example:

"IN"

language
string

Language code for supplier-written text (for example en). Optional. It is echoed in quote_context.language of each offer.

Example:

"en"

Response

contract_version
string
required

Response contract version, always 2.

Example:

"2"

success
boolean
required

True when the search was started.

Example:

true

message
string
required

Human-readable status. Do not parse it.

Example:

"Rooms fetched successfully"

data
object
required

The initial room response.