Add a route and watch what it costs to fly in

By the end you will have a route on your account, one live fare on screen, and the stored series that turns that fare into a demand signal for the nights it feeds.

What you need: an account with the Account API active, and the two airports you care about.

What it costs: creating the route is free. The live call consumes credits per request; the stored feed is the cheap read, and the credits go on the imports that fill it.

Why register a route if the live call needs nothing

This is the question worth answering first, because the real-time endpoint genuinely takes two IATA codes and a date and gives you fares — no entity, no setup, nothing to configure.

The entity exists for a different job. A fare on its own tells you almost nothing. Madrid–Barcelona at 180 € is expensive or cheap depending on what it cost yesterday, last week and the same week last year. What moves a revenue decision is the series: the same route, the same point of sale, re-priced day after day. Register the route and Veetal stores each extraction; then the feed read is cheap and repeatable, and every live call you were about to loop is a credit you did not spend.

Put another way: Real Time answers "what does it cost now". Feed answers "what has been happening to this route". Only one of the two is a leading indicator.

1. The airports, resolved for free

Airports are catalog data, so resolving them costs nothing — the catalog search (type=airports) is free, 0 credits, and the wizard's autocomplete resolves them for you while you type.

London alone offers seven airports with their IATA codes. This matters more than it looks: LGW and LHR are not the same inbound market, and a route built on the wrong one answers correctly about a city your guests are not flying from.

Airports resolve locally, which makes flights the most self-contained of the four entity types — it works even when the OTAs are having a bad day.

2. Create the route

On Flights, Add flights. Type a city and the autocomplete gives you its airports with their IATA codes. Then trip type, dates and passengers.

• Round trip needs a date range.
• One way takes a single date.

3. Point of sale is not the route

Two fields are required and easy to miss: LANGUAGE and COUNTRY.

They are not the origin of the flight. They are the point of sale — the market whose prices you want to see. The same seat on the same plane is priced differently to a browser in Spain and a browser in the United States, and which of those two you are watching is a decision, not a formality. If you are tracking German demand into Barcelona, the point of sale is Germany even though the route is the same one.

Leave one empty and the field turns red with This field is required, and Add flight stays disabled. That disabled button is the single most common "the form is broken" report on this screen.

The same field decides the currency you get back on the live endpoint: location=ES answers in euros, US in dollars, MX in Mexican pesos.

4. One live call, no setup

GET /v2/real-time/flight/rate/airport/{origin}/{destination}/{departure_date}

Add return_date for a round trip, adults, children, infants for the party, location and language for the point of sale, and order_by=price or recommended.

It answers in a few seconds with the flights on offer: airline, times, stops, baggage, CO2 and the segments of each itinerary. Being a Real Time endpoint it is cacheable — the cache window is configurable per API from 0 to 24 hours in the dashboard, and no_cache=true forces a fresh answer that is not stored as part of the parameters.

This call is the right tool for a one-off question: what does it cost to fly in for that congress weekend.

5. The same route, every day

For a series, activate the route on the flight rates Feed API and launch the first import by hand — read the credit estimate before you press, then put it on a schedule so the series keeps filling.

GET /v2/feed/flight/{flight_id}/rates

The flight_id is the id of the entity you just created, from GET /v2/account/flight. The shape follows the trip type: a one way returns flights[], a round trip returns outbound_flights[] and return_flights[], each flight carrying its airline, times, stops, baggage and CO2.

Pass import_id or import_date to read one specific extraction. Without them you get the latest — which is what you want on a dashboard, and not what you want when you are building the curve.

What this is a leading indicator of, and what it is not

It is not a booking count. Nobody sells you the number of people who bought a seat.

What it is: the price and shape of getting there. Fares climbing on a given week, cheap fares disappearing, direct flights selling out until only two-stop itineraries remain — that is the market tightening for those dates, and it happens while your own pace still looks ordinary. Cross it with the event calendar for the same city and you get the two halves of the same story: events tell you why the demand is coming, the route tells you whether it is already being bought.

What happens next

Register the two or three routes that actually feed your city — your main source markets, not every airport in the world — and pair the series with the events feed. The Flight-Demand Forecast recipe does exactly that with the data this setup produces.