Skip to main content
POST
Retrieve booked item IDs and per-item servicing eligibility using the Jinko booking reference
Authenticated API lookup for a booking the user already made. Guest access verifies the booking reference and last name; the integrating application still supplies API credentials. Use it when the traveler has their Jinko booking reference and last name, for example to look up the itinerary days later without signing in. Returns the full booking envelope: status, travelers, and itinerary items, each with its booked_item_id and its supplier confirmations in supplier_references (the airline’s record locator per airline, the hotel’s confirmation number, the rental reservation number). The flight itinerary in items[].confirmation.details.flight.legs is the one booked and ticketed. It is not refreshed from the airline afterwards: a schedule change or a cancellation made by the airline doesn’t appear here, and no webhook reports it. The customer contact you send at checkout (an email and a phone number, not necessarily the traveler’s) is passed on with the flight booking. Depending on how the flight was booked, it is sent to the airline as part of the reservation, or it stays with an intermediary booking system and Jinko can’t confirm that it reaches the airline. Whether an airline that has the contact uses it to tell anyone about a change is up to the airline.

Authorizations

X-API-Key
string
header
required

Body

application/json
booking_ref
string
required

Jinko booking reference. Call get_booking first, then select its booked_item_id for servicing.

Minimum string length: 1
Example:

"JNK-A0AUR2"

last_name
string

Required for guest lookup. A credential that owns the booking may omit it; ownership is checked by the platform.

Minimum string length: 1
Example:

"Doe"

intent
object

Response

Retrieve booked item IDs and per-item servicing eligibility using the Jinko booking reference

booking
object

The booked trip. Minimally described — the platform sends more (items, per-item confirmations, provider state) and all of it reaches you. The two *_support_level fields are a SNAPSHOT: a fare’s void window closes with time, so before acting on a refund or exchange read the level from a live POST /v1/refund_check or POST /v1/exchange_shop rather than from here. The flight itinerary (items[].confirmation.details.flight.legs) is the one booked and ticketed. It is not refreshed from the airline, and no webhook reports an airline's schedule change or cancellation.