Retry flight calls safely

Re-read your booking after an interrupted call, because an HTTP failure does not establish whether the supplier acted or your traveller paid. Use the same booking id while the outcome is unresolved.

Retry a 502

You can retry 502 supplier_unreachable with backoff when no stateful supplier outcome is unknown. A Duffel prebook, or a LiteAPI prebook whose fare check failed, holds no inventory when it fails this way; use a new idempotency key and a fresh offer if needed. An uncertain LiteAPI prebook instead returns 500 result_unknown, because it may have created an airline order.

Handle a 422

Fix the reason before repeating the request. A new offer or corrected passenger details can require a fresh prebook key. For LiteAPI, resolve any existing checkout payment with support before creating a replacement, because a booking refusal does not release or refund it.

Handle an unknown result

A 202 from book is not result_unknown: LiteAPI is still ticketing your booking, and you receive flight.booking.confirmed once it confirms. Do not book again; if it stays COMPLETE_IN_PROGRESS, contact support with your booking id.

For 500 result_unknown, read the booking before doing anything else:

1. If you see CONFIRMED, use the stored booking. Repeating a confirmed LiteAPI book may refresh pending payment evidence without purchasing again.
2. If you see COMPLETE_IN_PROGRESS on Duffel, do not book again. Contact support with your request id because the airline may have issued a ticket.
3. If you see COMPLETE_IN_PROGRESS on LiteAPI, keep the original booking id and contact support before sending another book request, because the supplier may already have issued the ticket.
4. If you see PREBOOK_IN_PROGRESS on LiteAPI, replay the same key to read its state and contact support. Do not create another checkout, because the first request may have created an airline hold.
5. If you see PREBOOK_IN_PROGRESS on Duffel after replaying the prebook's key, search again and prebook the new offer with a new key. The booking holds no inventory and has charged nothing, and its offer stays unavailable because a loyalty account update or a payment intent may still complete.

For an unresolved bag purchase, keep its idempotency key and contact support. You cannot avoid an unknown result by buying again with a new key.

Replay a prebook with the same key

Send x-idempotency-key on every prebook. With the same organisation and user, you receive the stored booking: 201 for creation, 200 for a replay. A replay does not restart a failed or interrupted prebook.

For LiteAPI, a replay while READY_FOR_COMPLETE re-reads the checkout. You receive meta.payment_sdk only after its identifiers, price and currency match the stored booking and payment. A mismatch returns result_unknown without a token. OEX replay omits checkout metadata, so a Duffel SDK token you lost cannot be read again, and a new key on the same offer answers 409 because the first booking still holds it: search again and prebook the new offer.

Book without a second key

Use the booking id as your handle. You receive the stored outcome for a completed booking. A concurrent Duffel book returns 409; wait and re-read. For an unresolved LiteAPI booking, contact support before another book request and keep the same booking id, because a replacement may buy another ticket.

Repeat a cancellation

Repeat cancel on CANCEL_IN_PROGRESS or CANCELED to read its outcome and restart a stopped workflow when needed. OEX refund requests use stable keys across retries. LiteAPI cancellation retries read supplier state first; you may see a canceled ticket with unknown refund amounts that need support review.

Keep learning