get_booking, select the flight item, then shop for exchange options and price the chosen offer. Show the traveler the new itinerary, fare conditions and the amount to pay or receive before asking them to confirm. Keep the same booking_ref and item_id throughout the exchange.
See Flight Exchange for the MCP workflow and exchange commit for the REST operation.
When an exchange can’t be refunded automatically
A cheaper exchange can need Jinko support to pay the refund, for example when it must be split across payments. Pricing tells the traveler that confirming the exchange sends it to support. Pricing alone does not open a support request or change the ticket. After the traveler confirms, commit the selected exchange. A refusal carryingmanual_handling.status: "pending" means the request is now with Jinko support. Tell the traveler:
This exchange can’t be refunded automatically, so it has been sent to Jinko support. They will complete it and refund you; there is nothing else to do.Do not present this as a completed exchange or ask the traveler to keep retrying. The existing ticket remains in place while support handles the request. The synchronous message is the notice; no separate email is sent when the request opens.
Track the request
Readget_booking for the flight item’s servicing.exchange:
While the request is open, the booking currency’s
servicing_summary has attention_required: true. After completion, the refund is included in the summary’s refunded. The usual exchange confirmation email includes the new itinerary and total refunded. The manual-exchange view is hidden if the item is being cancelled or has been cancelled.
What support does
Jinko support reviews the request, completes the exchange with the airline and refunds the traveler, splitting the refund across the booking’s payments when needed. If support cannot complete it, they close the request with a reason, andservicing.exchange reads failed. You don’t need to call anything while support handles the request.