Session lifecycle

A booking session is the state that links a search to the held booking it produces. Every booking-API call after the initial search references its session by sessionId. This page covers when a session is created, when it expires, and what it carries.

Origin

A new session is created on every successful POST /search/voyages or POST /search/packages. The response's sessionId is a UUID generated server-side. Sessions are not idempotent — repeating the same search creates a new session with a new sessionId.

Expiry

Each session has an idle expiry of 15 minutes. The timer resets to a fresh 15 minutes whenever the session is written to — the initial search (which creates it), POST .../create, and the apply/remove calls on addons, excursions, or supplemental tours. The GET sub-resource endpoints only read the session and do not reset the timer.

After expiry, every booking-API call against that sessionId returns:

404 Not Found
"Session expired or invalid."

There is no recovery path — start a new search to obtain a fresh sessionId.

Booking-type binding

Each session is bound to a single booking type at search time:

POST /search/voyages produces a voyage-only session. Only /bookings/create/voyage-only/... endpoints accept it.
POST /search/packages produces a package session. Only /bookings/create/package/... endpoints accept it.

Calling a voyage-only endpoint with a package session — or vice versa — returns:

400 Bad Request
"Booking session is not of type voyage-only."   (or "...package.")

Held-booking state

A session can hold one booking at a time:

Before create, the session is empty. GET/POST/DELETE on any sub-resource endpoint — and POST .../confirm — returns 409 Conflict until a held booking exists.
POST /bookings/create/... populates the session with a held booking. A second create on the same session returns 409 Conflict.

Confirm

A successful confirm finalizes the held booking and ends the session. Any further call against the sessionId returns 404 Session expired or invalid.