How do I get started with Ignav and what does it cost to try?

Updated

Ignav is a self-serve flight prices and booking links API. You can start without paying: sign up for a free API key, get 1,000 free requests, and no credit card is required. Only successful requests are billed, and there is no rate limit. If you want to test the workflow before writing code, the site offers a Playground alongside the docs.

What you get before paying anything

The free tier is enough to validate the core flow — search fares, then turn an itinerary into a booking link.

Item What the site states
Free requests 1,000
Credit card Not required
Billing rule Only successful requests billed
Rate limit None
Entry points API key, Playground, docs

Pricing beyond the free requests is not specified in the available material, so treat the 1,000 requests as the trial scope and check the pricing page for current terms before scaling.

Getting started in three steps

1. Get an API key

Sign up for free. You start with 1,000 requests and no credit card is required. The API key is passed in the X-Api-Key header on each request.

2. Search fares

Start with one-way or round-trip. Flexible search also supports one or two ordered legs and open-jaw trips. A one-way request looks like this:

curl -X POST "https://ignav.com/api/fares/one-way" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"origin":"SFO","destination":"JFK","departure_date":"2026-11-03"}'

The response is structured JSON. Each itinerary includes price, outbound segment details (carrier, flight number, airports, local and UTC times, aircraft, duration), cabin class, whether a self-transfer is required, and an ignav_id.

3. Fetch booking links

Pass an ignav_id to request direct airline and OTA booking URLs. This is the step that turns a fare result into something a user can act on.

What the response actually contains

The example response for SFO → JFK shows the fields you can build on:

  • price: amount, currency, and a status such as verified
  • outbound: carrier, duration, and a segments array with flight numbers, operating carrier, departure/arrival airports, local and UTC times, timezones, and aircraft
  • cabin_class and requires_self_transfer
  • ignav_id: the handle used to fetch booking links

Because times are given in both local and UTC, you can display schedules without doing timezone math yourself.

What you can build with it

The site groups intended use into three patterns:

  • Flight search apps — search fares, filter results, and fetch booking links for any route.
  • Price trackers and alerts — poll routes on a schedule, compare fares over time, and notify users on drops.
  • AI travel tools — look up airports, search live fares, and generate booking links from AI workflows. An MCP server is offered for agent integration.

Client options and common sticking points

cURL, Python, and JavaScript are supported, and the Playground lets you try requests without setting up a project. Practical things to plan for:

  • The ignav_id is per itinerary, so store it if you want to fetch booking links later rather than re-searching.
  • Check requires_self_transfer before presenting an itinerary as a single-ticket trip.
  • Since billing counts only successful requests, failed calls during development should not consume your free allowance — but confirm this against the pricing page if your usage grows.

If your goal is to see whether the data fits your product, the fastest path is: get a key, run one one-way search in the Playground, then fetch a booking link from the returned ignav_id.