AI Travel Tools

Integrate live flight data into AI travel agents, assistants, and chatbots. Ignav's endpoints map cleanly to tool/function calling patterns.

Tool design pattern

The typical pattern is three tools chained together:

1. Airport lookup — resolve a natural-language city name to IATA codes
2. Fare search — search for flights with the resolved airports
3. Booking links — generate a booking URL for a selected itinerary

1. Airport lookup

Users say "Tokyo" but the API needs NRT or HND. Use airport search to resolve ambiguous inputs.

curl "https://ignav.com/api/airports?q=tokyo&limit=3" \
  -H "X-Api-Key: YOUR_API_KEY"

2. Fare search

Pass the resolved airport codes to a fare search. The response includes structured itineraries your AI can reason over — prices, carriers, durations, stops.

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":"NRT","departure_date":"2026-04-25"}'

3. Booking links

Once the user confirms an itinerary, pass its ignav_id to get a direct booking URL the AI can present.

curl -X POST "https://ignav.com/api/fares/booking-links" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ignav_id":"5e4fcd2f1dc340649eb19f6ee2afb57a"}'

Response shaping & guardrails

Fare responses can be large. Consider extracting a summary (cheapest price, number of options, shortest duration) rather than passing the full JSON to the LLM context. Use max_stops, cabin_class, and max_price filters to reduce result set size before the response reaches your model.

Fares change continuously — don't cache results for long or let the AI quote exact prices from stale data. Always present a booking link so the user sees the live price at checkout.