AI Travel Tools

Add live flight data to AI travel agents, assistants, and chatbots. You can use Ignav's endpoints as tools or functions for your model.

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 the AI can compare by price, carrier, duration, and stops.

Use the dedicated endpoints for ordinary one-way and round-trip tools. If the agent accepts multi-city or open-jaw requests, expose flexible search with one or two ordered legs so the complete trip stays one priced itinerary.

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-11-09"}'

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 the number of results 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.