Launch

Going live checklist

Work through this list against your sandbox before switching to production. Each item is here because skipping it has cost someone a booking.

Account and keys

  • An agency admin has signed the distribution agreement in the portal.
  • You've created a production key with Agent access, named for the system that uses it.
  • The key lives in a secret manager, only on your servers — never in a browser, app or repository.
  • You know how to rotate and revoke it (Authentication).
  • Your wallet has enough credit for expected volume, in the currency you'll search in.
  • Destinations are resolved with suggest before searching.
  • Every search uses your wallet currency, and flight, activity or transfer rows in any other currency are hidden.
  • Occupancy has one entry per room, with every child's age; residency is the lead guest's passport country.
  • Results render straight away and update while the search is partial.
  • You page with cursors rather than searching again.
  • You call GET /search/capabilities before offering a product in a market.

Checkout

  • You price-check once, at checkout, and book within 10 minutes of it.
  • Price and policy changes are shown to the traveller before changesAcknowledged is sent.
  • Checkout shows the total, cancellation terms, taxes payable at the hotel and rate comments.
  • Package rates are offered only inside a package.
  • Every guest has a real name; the lead guest has an email and phone.
  • rate_unavailable sends the traveller back to a refreshed rate sheet.

Booking

  • A fresh Idempotency-Key is generated per attempt and stored with your order before the request is sent.
  • Timed-out booking calls are retried with the same key.
  • You branch on data.state, not the HTTP status, and handle every state — including supplier_pending, failed and manual_review.
  • bookingId and orderRef are saved against your order.
  • Pending bookings are polled with refresh-status, then monitored.
  • Holds are paid or cancelled before their payment deadline.

After booking

  • Travellers receive a voucher, and supplier vouchers for activities and transfers are passed through unchanged.
  • Pickup-time notices on transfers appear before confirmation and on the voucher.
  • Cancellations use the booking's cancellation terms and an idempotency key.

Resilience

  • Client timeouts: 30 seconds for search and price-check, 120 seconds for booking and cancellation.
  • 429 waits for Retry-After; 503 and network errors back off exponentially.
  • You ignore response fields and states you don't recognise instead of failing.
  • You log error.code, the endpoint and the time for every failed call.