Flight Cancellations & Refunds

This page explains what partners can rely on for voluntary flight cancellations from the public Flights OpenAPI. Servicing models, airline IRROPs, and the flat service fee are covered in Flights — Support & Billing Model.

Quote first, then cancel

Auth: X-API-Key on https://api.liteapi.travel/v3.0, same as other Flights calls.

Quote fields (documented)

From the quote response data[] items:

• confidence — confirmed | estimated | heuristic | unknown
• isRefundable / isVoidable — eligibility flags (isVoidable ≈ void window / cancel without penalty)
• refund.display.amount / currency — potential maximum refund with margin applied on display. Not granted until cancel completes; final may be lower or zero
• penalty.display.amount / currency — estimated penalty (display amounts use margin where the schema says so)

Cancel outcome fields (documented)

Final / pending cancel payloads expose:

• cancellation_fee — total cancellation penalty with margin applied
• refund_amount — amount refunded or to be refunded with margin applied
• currency — currency of those two fields
• destination — where refunded money goes: original_payment | agency_deposit | voucher | bsp_settlement | manual | unknown

While cancel is pending (HTTP 202), the booking can stay CONFIRMED until the airline finalizes. Subscribe to flight booking webhooks for asynchronous status updates. Treat the final cancel result (and webhook) as authoritative for money movement — not a hand-computed difference from search pricing.

Settlement semantics that are documented

1. Margin on cancel money — Quote refund/penalty display amounts and cancel refund_amount / cancellation_fee are described as margin-applied (selling-side display), not raw supplier-only figures.
2. Supplier vs selling on the original ticket — FlightPrice.base / taxes / fees are supplier values and never include partner markup; FlightPrice.total is the selling total including markup (and platform fees when present). PDF/confirmation lines that show supplier taxes beside a Billing Summary that embeds markup are consistent with that model.
3. Authoritative cancel money — Use final refund_amount, cancellation_fee, destination, and the cancellation webhook — not arithmetic you derive from fare + markup yourself.

What is not in the public docs

Do not invent partner ledger rules. The following are not defined in the Flights OpenAPI / published guides as of this page:

• Whether a remittance to the partner equals “supplier refund only” vs “selling refund” beyond the margin-applied wording on cancel fields
• Explicit commission reversal mechanics (full / partial / fare-only / tax-only)
• A universal rule that seats and baggage are never refunded or that ancillary commission is always retained — ancillary outcomes follow airline / provider rules and appear only as aggregate cancel amounts unless a future schema adds component lines
• Whether platform fees (ticketing / merchant-of-record / ancillary) are refunded or retained on cancel
• A documented rounding algorithm or reconciliation tolerance for Billing Summary vs booking response vs PDF

If you need ledger-level settlement rules for finance automation, open Request Assistance (or your account manager) with bookingId, environment, and the cancel quote + cancel response payloads (redact card data).

Partner checklist

1. Call GET cancel quote; show the traveller the quote as a potential maximum.
2. Call POST cancel; handle 202 as pending, not as a finished refund.
3. Reconcile to final refund_amount / cancellation_fee / destination (+ webhook).
4. Present traveller taxes from supplier taxes when you want airline tax lines; keep markup in the selling total — that matches FlightPrice.
5. Do not hard-code “ancillaries never refund” or a ±tolerance unless your contract states it.

Related references

• GET cancellation quote
• POST cancel a booking
• Search Flights (Rates) — FlightPrice supplier vs selling
• Flights — Support & Billing Model