How the Ignav API Turns a Flight Question into a Booking Link

Ignav's flight API answers a route question in two steps: a fare search returns live itineraries, each carrying an ignav_id, and a second call passes that ID to get booking URLs for airlines and OTAs. You need an API key, and the flow works for one-way, round-trip, flexible, and open-jaw searches. The site advertises 1,000 free requests, no credit card required, and billing only on successful requests.

The two-call flow

The API is built so that a question ("what does SFO to JFK cost on this date?") becomes a clickable booking link without scraping or manual lookup.

1. Search fares — send origin, destination, and date. The response contains itineraries with price, carrier, segments, times, and an ignav_id per itinerary.
2. Fetch booking links — pass the ignav_id back to the API to request direct airline and OTA booking URLs.

Every itinerary includes an ignav_id specifically so you can use it to fetch booking links. That ID is the handoff between the two calls.

Step 1: Request fares

A one-way search is a POST to /api/fares/one-way with your key in the X-Api-Key header:

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. A sample itinerary looks like this:

{
  "origin": "SFO",
  "destination": "JFK",
  "departure_date": "2026-11-03",
  "itineraries": [
    {
      "price": { "amount": 299, "currency": "USD", "status": "verified" },
      "outbound": {
        "carrier": "American Airlines",
        "duration_minutes": 330,
        "segments": [
          {
            "marketing_carrier_code": "AA",
            "flight_number": "100",
            "operating_carrier_name": "American Airlines",
            "departure_airport": "SFO",
            "departure_time_local": "2026-11-03T08:00:00",
            "departure_timezone": "America/Los_Angeles",
            "departure_time_utc": "2026-11-03T15:00:00Z",
            "arrival_airport": "JFK",
            "arrival_time_local": "2026-11-03T16:30:00",
            "arrival_timezone": "America/New_York",
            "arrival_time_utc": "2026-11-03T20:30:00Z",
            "duration_minutes": 330,
            "aircraft": "Boeing 777"
          }
        ]
      },
      "cabin_class": "economy",
      "requires_self_transfer": false,
      "ignav_id": "5e4fcd2f1dc340649eb19f6ee2afb57a"
    }
  ]
}

What to read from this:

• price.status — "verified" signals the fare was checked; treat unverified values with more caution in a price tracker.
• requires_self_transfer — false here means a single through-ticket; true would mean the traveler collects bags and re-checks, which matters for connection risk.
• ignav_id — the value you carry into step 2.
• Local and UTC times are both present, so you can display local departure/arrival without doing timezone math yourself.

Step 2: Fetch booking links

Pass the ignav_id to request direct airline and OTA booking URLs. The docs describe this as the second half of the same flow: search fares, then fetch booking links for any route. The result is a link straight to the airline (or an OTA), so the user can complete the purchase at the source rather than through a reseller layer.

Search types the flow supports

Open-jaw means you fly into one city and out of another — useful for multi-city trips where the return isn't from the arrival airport.

Where this fits

The same two-call pattern serves three common products:

• 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 when prices drop. The price.status field and the stable ignav_id are what make repeated polling comparable.
• AI travel tools — look up airports, search live fares, and generate booking links from AI workflows. An MCP server is available for agent integration.

Practical notes and gotchas

• Keep the ignav_id. It's the only thing linking a displayed fare to its booking link. If you cache itineraries, cache the ID with them.
• Billing is per successful request. The site states only successful requests are billed, with 1,000 free requests to start and no rate limit. Confirm current terms on the pricing page before scaling a polling job.
• Polling has a cost shape. A price tracker that checks many routes frequently multiplies requests; since billing follows successful requests, design your schedule around what you actually need to alert on.
• Self-transfer itineraries need a UI warning. When requires_self_transfer is true, the traveler is responsible for the connection — surface that clearly.
• Booking links go to the source. The link points to the airline or an OTA, so final price and availability are confirmed at checkout, not by the API response.

Start by signing up for a key, running one fare search in the Playground or via cURL, then passing the returned ignav_id to the booking-link endpoint. That single round trip is the whole mechanism.