Identifier stability

The V2 API exposes two kinds of identifiers. Choose the right kind for what you need to do.

Stable identifiers — safe to persist

Use these when storing data in your own database, displaying values to customers, or comparing across requests over time:

Identifier	Source
Booking id	Returned by /bookings/create/.../confirm. The durable handle for a confirmed booking.
packageCode	/packages data[].packageCode. Also the search input on /search/packages.
Port codes	/refdata/ports [].code.
Ship codes	/refdata/ships data[].code.
Cabin grade codes	/refdata/cabin-grades [].code.
Addon, excursion, and supplemental-tour codes	The code field on every entry returned by the get-applicable endpoints.
Promotion codes[]	/promotions data[].codes[]. The promotion-code strings (e.g. C1-26-US-W2WI30) are the partner-facing identifier for a promotion.

Snapshot-only identifiers — do not persist

The id fields on read-only inventory endpoints are valid only within a single response cycle:

Field	Endpoint
Voyage id	/voyages data[].id, and /promotions data[].applicableVoyages[].
Package id	/packages data[].id, and /promotions data[].applicableTours[].
Promotion id	/promotions data[].id, and /voyages / /packages data[].promotions[].

Use these only to cross-reference entries you fetched together — for example, resolving the applicableVoyages array on a /promotions entry against the data[].id values in a /voyages response retrieved at the same time. Do not store them, send them to customers, or compare them across requests.

Booking-flow identifiers

Identifiers used inside the booking flow live in the Session lifecycle — sessionId is scoped to a single booking session and is not a persistent identifier; guestId is per-session, assigned at search time. The booking id returned by confirm is the only persistent identifier produced by the booking flow.