Skip to main content
POST
Cancel a hotel booking and get a refund when eligible. Preview and commit in one call — POST /v1/hotel_cancel_preview plus /v1/hotel_cancel_commit is the two-step form, which shows the customer the refund before anything is cancelled. `refund_amount` is what the CUSTOMER gets back; the supplier's own net figures are under `provider_figures`. Returning the money outlives this call: poll the `operation` handle with POST /v1/hotel_cancel_status. Every call here needs API authentication (an API key or a Bearer token); this is about which mode identifies the booking. Use EXACTLY ONE: provider_booking_id, which additionally requires a credential that OWNS the booking, or booking_ref + last_name, which identifies it without one. Sending both is a 422.
Cancel a hotel booking when the traveler can no longer make the stay or wants to drop a hotel from a multi-item trip. The call is idempotent: retrying the same cancellation re-serves the stored result rather than charging or refunding twice. Works with guest auth (booking ref + last name) or the authenticated shortcut (provider booking ID). Two auth modes:
  • Guest: booking_ref + last_name together.
  • Authenticated: provider_booking_id (optionally with provider).
The two modes are mutually exclusive.

Authorizations

X-API-Key
string
header
required

Body

application/json
provider_booking_id
string

The supplier's own booking reference. OWNER mode: beyond the API authentication every call needs, this one requires a credential that OWNS the booking — a tenant-bound key reaches its whole tenant, any other credential must belong to the booking's own user. Mutually exclusive with booking_ref + last_name; sending both is rejected with 422. An unknown reference, another tenant's booking and another user's booking are all answered identically, so this field cannot be used to discover which supplier references exist.

Example:

"NUITEE-88231"

provider
string

A hint only. The provider stored on the resolved booking wins, so a stale value here cannot send the cancellation to the wrong supplier.

Example:

"nuitee"

booking_ref
string

The Jinko reference. GUEST mode: pair it with last_name and the pair identifies the booking on its own — API authentication is still required, as on every call here, but the credential does not have to own the booking. Mutually exclusive with provider_booking_id; one without the other is rejected with 422.

Example:

"JNK-H1ZK90"

last_name
string

The lead traveller's surname. Required with booking_ref, and only with it.

Example:

"Carrard"

intent
object

Response

Cancel a hotel booking and get a refund when eligible. Preview and commit in one call — POST /v1/hotel_cancel_preview plus /v1/hotel_cancel_commit is the two-step form, which shows the customer the refund before anything is cancelled. refund_amount is what the CUSTOMER gets back; the supplier's own net figures are under provider_figures. Returning the money outlives this call: poll the operation handle with POST /v1/hotel_cancel_status. Every call here needs API authentication (an API key or a Bearer token); this is about which mode identifies the booking. Use EXACTLY ONE: provider_booking_id, which additionally requires a credential that OWNS the booking, or booking_ref + last_name, which identifies it without one. Sending both is a 422.

provider_booking_id
string
Example:

"NUITEE-88231"

provider
string
Example:

"nuitee"

status
string
Example:

"cancelled"

operation
string

The cancellation this call started ("svc_…"). Cancelling the booking at the supplier and returning the money are separate steps, so this call answering does not mean both finished — poll the handle with POST /v1/hotel_cancel_status until state is terminal.

Example:

"svc_01J7ZR5Q2KME8V4T"

state
enum<string>

Where the cancellation has got to. in_progress — running; keep polling. attention_required — stalled on something a person at Jinko has to resolve (reason names it); keep polling, and do not report it to the customer as a failure, because the booking may already be cancelled at the supplier. succeeded and failed are terminal: the supplier outcome and the money are both settled and nothing further will change.

Available options:
in_progress,
attention_required,
succeeded,
failed
refund_amount
object

THE CUSTOMER FIGURE: what goes back to the payment method that paid for this booking — what the customer paid for it, less penalty_amount. Up to contract version 0.3.0 this field carried the SUPPLIER's net refund instead, which on a booking sold at a margin is a smaller number; the supplier's figure now lives in provider_figures.refund_net. Absent when no refund was scheduled — absent is not zero.

customer_refund_amount
object
deprecated

Deprecated alias of refund_amount, carrying the same value. It existed because refund_amount used to be the supplier figure; now that refund_amount IS the customer figure the alias is redundant. Read refund_amount — this field is removed in the next contract version.

penalty_amount
object

The cancellation penalty withheld from the customer, on the same basis as refund_amount: what they paid, less this, is what they get back. The penalty the SUPPLIER withheld from Jinko is provider_figures.penalty_net.

provider_figures
object

The supplier's own net figures, for reconciliation — never what the customer receives. refund_net is what the supplier returns to Jinko and penalty_net what it withheld from Jinko; on a booking sold at a margin both differ from the customer figures. Show the customer the top-level refund_amount / penalty_amount, never these. currency is the currency the supplier settles in, which can differ from the currency charged.

connector_reference
string
Example:

"cxl_2f90a1c3"

cancelled_at
string
Example:

"2026-06-01T12:34:56Z"

idempotent
boolean
Example:

false