Production Checklist

Use this checklist to run the Ignav API reliably in production. It brings the recommendations from across the docs together in one place.

Website search forms

Run fare searches only when the user submits a search. Do not run fare searches while fields change, on page load, or from a refreshable GET URL. Use a server-side POST or AJAX endpoint so refreshes and shared links do not replay paid searches.

Debounce airport autocomplete and fetch booking links only when a user chooses an itinerary.

Retry strategy

Retry network failures and HTTP 424 responses with code unable_to_complete_request using exponential backoff. For unsupported_search, try earlier dates instead of retrying the same search. Other 4xx errors are client issues and should not be retried.

Handle empty results

An empty itineraries array is a valid successful response, not an error. It means no fares matched your search criteria. Show a "no results" state in your UI instead of a failure.

Price display

Fares and availability change continuously. Display prices as approximate with phrasing like "from $299" and link to a booking page where users can confirm the current price.

Use carrier codes, not display names

The outbound.carrier, inbound.carrier, and flexible-search legs[].carrier fields are display names that may vary. When you need a stable identifier for an airline, use marketing_carrier_code from the segments array.

Airport lookups

Use the airport search endpoint to resolve user input to IATA codes before fare searches. Each successful lookup counts as one request.

Booking links

Prefer using ignav_id for booking link lookups — it's simpler and more accurate than specifying flight details manually. Booking links open airline or OTA booking pages. Check each link's specificity when provided: some links are intended to preselect flights, while others show search results. An omitted value leaves the selection behavior unspecified.

Read the returned itinerary before displaying the final choice because a stale flexible-search result may be refreshed during booking lookup. When flexible booking_options are split, use their leg_indexes to show which purchases are needed.

Error handling

All error responses include a machine-readable code field and a human-readable message. See the errors reference for the full list.

Billing

Only successful (HTTP 200) fare searches, cheapest-dates searches, booking link lookups, and airport searches are billed. Failed requests are never billed. Monitor your usage from the dashboard.