Skip to main content
POST
Check how a flight refund or void ended
Report where one refund or void has got to, named by the operation handle a commit (or POST /v1/refund_commit) returned. Read-only. state is the platform view, keep polling while it is in_progress or attention_required, both of which mean the operation is still alive; attention_required means a Jinko agent has it, and park_deadline says how long that lasts. operation_kind says which operation actually ran. provider is what the airline says, including what became of each ticket and EMD, an operation has done its work when every document it covers has reached a terminal state. money is where the refund itself has got to; the two move independently, so the tickets can read refunded while the money is still in flight. Do not tell a customer they have been refunded until money.vehicle_state says paid. Same auth modes as flight_refund_preview.

Authorizations

X-API-Key
string
header
required

Body

application/json
operation
string
required

The "svc_…" handle from a commit, or from POST /v1/refund_commit.

Example:

"svc_01J7ZR5Q2KME8V4T"

provider_reference
string

The CONNECTOR's own order id for this flight booking — the Sabre PNR for a Sabre booking, the TravelFusion booking reference for a TravelFusion one. NOT the airline record locator, which names the carrier's own copy of the reservation and is answered 404 here, identically to an unknown booking. 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.

Example:

"QQIUIQ"

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_reference; 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

Where the refund or void has got to

operation
string
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
reason
string

Why the operation is stalled. Present with state: attention_required; the value names what Jinko has to resolve, and needs nothing from the caller.

Example:

"settlement_review"

park_deadline
string

When a parked operation stops waiting for Jinko and is settled or failed. Present with state: attention_required; it is how long "keep polling" lasts.

Example:

"2026-09-10T12:15:00Z"

next_run_at
string

When the platform next drives this operation by itself. Informational — polling sooner does not make it run sooner.

Example:

"2026-09-03T12:20:00Z"

provider
object

The airline's record. It can show the tickets refunded while the money is still moving — that is the normal middle of a refund, not a discrepancy.

money
object

The refund and where it has got to. Read vehicle_state before telling a customer they have been refunded.

operation_kind
enum<string>

Which operation ran — a refund under the fare rules (cancel) or a void of the original charge (void). The same field the preview quoted, so what was quoted and what ran compare directly.

Available options:
cancel,
void