Flight API: introduction

The AirIQ flight API lets your system search flights, confirm a price, add ancillaries and seats, book (paid or on hold), and read the booking back. Every call is JSON over HTTPS with a bearer token. This site shows the real requests and replies of each step, captured on our test environment, so you can build against what the API actually sends.

The flow

Numbers are the order of calls. Ids pass from one step to the next: search gives option_id and price_id, reprice gives itinerary_id, book gives booking_id.

Booking flow (paid booking)
Partner system
has an API key
→
1 generate-token
api_key → bearer token, 4 hours
→
2 search
segments, passengers → option_id, price_id
→
3 reprice
items → itinerary_id, requirements, price
→
4 ancillaries · 5 seat map
optional, by itinerary_id
→
6 book
passengers, ancillaries, GST; pay or hold
→
7 details
status, PNR, tickets
Hold branch
6 book is_hold=true
status ONHOLD, pay_till
→
8 confirm-hold
pay from your wallet, ticket → SUCCESS
or →
9 release
give the PNR back → PNR_RELEASED

Authentication

  1. Your account manager gives you an API key (it starts with aiqo_). Keep it on your server only.
  2. Exchange it for a bearer token with POST /generate-token. The token lasts 4 hours; renew it before it expires.
  3. Send Authorization: Bearer <token> on every other call.

How to read a search reply

  • results[] groups options by the journey indexes their fares cover: one way = one group [0]; a return sold per direction = groups [0] and [1]; a combined return fare = one group [0, 1]. Pick one option and one fare per group until every requested journey is covered.
  • option_id identifies the flights, price_id the fare on them; both go to /flights/reprice. Ids are valid until valid_till (60 minutes).
  • A fare prices the whole option: one object per requested passenger type (adult, child, infant), each with its fare (base, taxes, total, net, pax_count), booking_class, fare_basis and baggage. No amount appears anywhere else, never inside segments[].
  • Segment view (detail=segment): segments[] on every fare, one entry per flight matched by segment_index, same fields per flight.
  • fare_rules on a fare maps each journey index to an id (fr_1, fr_2, …) in the top-level fare_rules; a missing index has no rule known at search. Ids mean nothing outside this reply.
  • Baggage is {kg} and/or {pieces}; absent = not included or not known. Flight segments carry airport codes only (from, to).
  • Times are local to the airport, format YYYY-MM-DDTHH:MM:SS, no zone; valid_till carries its offset.
  • A missing field is zero, false or not applicable. The reply has no $schema field.

Where to go next

  • Test cases: 31 real flows (search, reprice, ancillaries, seat map, book on hold, details, release), each with its request and reply and a short list of what came back.
  • Reference: every endpoint with an example request, an example reply, notes and the error codes it answers with.
  • JSON viewer: open any captured request or reply as a collapsible tree with search.