June 15, 2026 · 7 min read · Data

IATA codes lie: a city has many airports, but APIs return one.

A user asks "nearest airport to London." Your API returns LHR. The user is staying near Stansted. They book a cab to Heathrow, spend three hours and £60, and write your product a one-star review. The principal-airport approximation is correct on average and wrong specifically — and specifically is what matters for trip planning.

Cities with multiple airports

A surprising number of major cities have more than one commercial airport, and the choice between them depends on the route, the airline, and where in the city the traveler is staying.

What the API returns by default

GET /v1/cities/london

{
  "city_id": "london",
  "name": "London",
  "iso_alpha2": "GB",
  "context": {
    "airport": {
      "iata": "LHR",
      "name": "Heathrow",
      "is_primary": true
    }
  }
}

The context.airport object exposes the principal airport — the one most travelers default to, weighted by international long-haul traffic. It's the right answer for "what airport should I fly into" 70% of the time. It is not the right answer for everyone.

Querying alternates

The /v1/airports endpoint returns the full list with structured metadata:

GET /v1/airports?city_id=london

[
  { "iata": "LHR", "name": "Heathrow",   "is_primary": true,  "distance_km": 24, "annual_pax_m": 79 },
  { "iata": "LGW", "name": "Gatwick",    "is_primary": false, "distance_km": 45, "annual_pax_m": 46 },
  { "iata": "STN", "name": "Stansted",   "is_primary": false, "distance_km": 60, "annual_pax_m": 28 },
  { "iata": "LTN", "name": "Luton",      "is_primary": false, "distance_km": 50, "annual_pax_m": 16 },
  { "iata": "LCY", "name": "City",       "is_primary": false, "distance_km": 11, "annual_pax_m": 4  },
  { "iata": "SEN", "name": "Southend",   "is_primary": false, "distance_km": 60, "annual_pax_m": 1  }
]

Now your application can rank by traffic, by distance, by typical airline mix, or by ground-transit duration — which is what users actually care about, and which doesn't track distance.

Why distance-based selection fails

The naive heuristic — "return the airport closest to the city centroid" — produces wrong results in three predictable ways:

  1. Closest by km isn't closest by minutes. Heathrow is 24km from central London but 15 minutes by Elizabeth Line. Stansted is 60km but a 45-minute Express. City Airport is 11km but no direct rail. The metric the user cares about is door-to-door time, which depends on where they're staying.
  2. Domestic vs international flights load different airports. A user flying London → Edinburgh probably wants LCY or LHR (BA) or LGW (BA), and definitely doesn't want STN (Ryanair to Edinburgh departs at 6am). The right airport depends on the airline set for the route, not the destination's distance.
  3. Low-cost carriers sequester themselves. Ryanair operates almost exclusively from STN and LTN. easyJet skews LGW and LTN. Returning LHR for "cheapest flight to Barcelona" is wrong by definition.

The right shape for AI trip planners

For a trip-planning AI, the airport selection should be a function of:

The /v1/airports payload gives you the inputs. The selection logic stays in your product because it's the part that encodes your UX opinion. We don't try to make that decision for you — we just make sure you have the data you need to make it correctly.

Sign up — free See India coverage →