Production Checklist

Everything you need to run the Ignav API reliably in production. This page consolidates best practices from across the docs into a single reference.

Retry strategy

Retry network failures and HTTP 424 responses with exponential backoff. A 424 means an upstream dependency was temporarily unavailable — these are always safe to retry. 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. Don't treat it as a failure — show a "no results" state in your UI instead.

Caching

Fares and availability change continuously. Short cache windows (a few minutes) are fine for reducing redundant requests, but don't cache results for more than a few hours. Display prices as approximate with phrasing like "from $299" and always link to a booking page where users see the live price.

Use carrier codes, not display names

The outbound.carrier and inbound.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 directly to the airline or OTA checkout page with the flight pre-selected.

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 and booking link lookups are billed. Failed requests are never billed. Monitor your usage from the dashboard.