Designing the user experience layer in a flight app. How to build the UX around flight data — destination search with autocomplete, location-based airport detection, and proactive status notifications — using documented flight API endpoints.
Every flight application is really two things working together. There is the data layer — the flight statuses, schedules, positions and routes that the app is built around. And there is the experience layer — everything that determines how a user actually interacts with that data: how they search, how they input where they are going, how they stay informed. The data layer gets most of the attention because it is the obvious hard part. But the experience layer is what users actually judge the app by.
This is worth dwelling on, because the two layers fail differently. A data problem produces a wrong answer. An experience problem produces friction — the user has to work harder than they should, and a competing app that asks less of them wins. A flight app can have flawless underlying data and still feel clumsy if the search box does not understand what the user types, if it makes them hunt for their departure airport, or if it forces them to keep refreshing to find out whether their flight is delayed.
This article is about designing that experience layer well. It focuses on three points where users most often meet friction in a flight app — searching for a place, identifying where they are flying from, and staying updated on changes — and how to design each one to reduce that friction. These are standard patterns in any well-built travel product, not exotic features; the point here is how to implement them thoughtfully, using documented flight API endpoints. For the broader integration picture, see Travel APIs for Developers; this guide zooms in specifically on the user-facing experience.
"Users do not experience your data. They experience your interface to it. A flight app is judged not by the quality of the schedule behind the search box, but by whether the search box understands 'frankfrt' and finds the airport before the user finishes typing."
The first thing most flight apps ask a user to do is tell the app where they want to go. This is deceptively hard to get right, because of a gap between how users think and how aviation data is structured. Users think in place names — "Paris," "New York," "Madrid" — and often misspell them, or type them in their own language. Aviation data is keyed on codes — CDG, JFK, MAD. Bridging that gap is the job of a good destination search.
The naive approach — a plain text field that expects an exact match or a code — pushes all the work onto the user. A well-designed search does the opposite: it anticipates what the user means as they type, tolerates spelling variation, and works across languages. This is the classic autocomplete pattern, and it is what turns a frustrating search box into an effortless one.
The AirLabs Name Suggestion API is built for exactly this. Its own documentation frames it as a way to improve the user experience by implementing intelligent autocomplete for destination names, working "in any language and possible spelling." A request takes a partial query as the user types:
GET https://airlabs.co/api/v9/suggest?q=spain&api_key={KEY}
{
"countries": [{ "code": "ES", "name": "Spain", "currency": "EUR" }],
"airports": [{
"name": "Matthew Spain Airport",
"iata_code": "SQS",
"city": "San Ignacio",
"country_code": "BZ",
"popularity": 26989
}],
"cities": [{ "name": "Port Of Spain", "city_code": "POS", "popularity": 15490 }]
}Several design details make this a strong basis for a search experience. The query accepts a partial name of an airport, city or country — so the same box handles all three kinds of search. The lang parameter takes a two-letter language code, supporting the multilingual searching that international travel apps need. And critically, every result carries a popularity value, which lets you rank suggestions so that the airports and cities users most likely mean rise to the top — the single most important factor in an autocomplete feeling "smart."
The response is also structured to support rich suggestion interfaces. Rather than a flat list, it groups results into airports, cities and countries, and additionally returns relational groupings — airports_by_cities, cities_by_countries, airports_by_countries and more. This lets you build a search dropdown that, when a user types a country, can immediately offer its main airports, or when they type a city, offer the airports serving it. The slug field on each result gives you a clean, URL-friendly identifier for routing within your app.
Designed well, this turns the very first interaction — telling the app where you want to go — from a point of friction into one that feels like the app is reading the user's mind.
The second common friction point is the departure side. Many flight apps ask users to select their origin airport from a list, or to type it in — which assumes the user knows which airport to use. For someone in a large metropolitan area with several airports, or a traveler in an unfamiliar city, that assumption often fails. Making the user figure out their own nearest airport is friction the app can remove entirely.
The better design uses the device's location to detect nearby airports automatically. Instead of "choose your departure airport," the app can say "here are the airports near you" — or simply pre-select the closest one. This is the difference between an app that makes the user orient themselves and one that orients itself around the user.
The AirLabs NearBy API is designed for this. Given a latitude and longitude — for example from the device's geolocation — it returns nearby airports and cities, each with a distance value, sorted by proximity:
GET https://airlabs.co/api/v9/nearby?lat=-6.1744&lng=106.8294&distance=20&api_key={KEY}
{
"airports": [{
"iata_code": "HLP",
"name": "Halim Perdanakusuma Airport",
"distance": 12.348
}, {
"iata_code": "CGK",
"name": "Soekarno-Hatta International Airport",
"distance": 19.893
}]
}The distance field — in kilometers from the requested point — is what makes this directly usable for a location-aware experience. Because results come sorted by distance, the nearest airport is simply the first result, ready to pre-select. The distance parameter sets the search radius, so you can show all airports within, say, 50 km for a city with multiple options, or tighten it when you only want the single closest. For metropolitan areas served by several airports, this naturally surfaces all of them, letting the user pick with full information rather than guessing.
This is a small design change with an outsized effect on the feel of an app: the user opens it and their departure airport is already there, correct, without a single tap.
The third friction point comes after booking or tracking is set up: keeping the user aware of changes. Flights change — they get delayed, gates move, flights divert. The question is who does the work of noticing. In a poorly designed experience, the user has to keep opening the app and refreshing to check whether anything changed. That is friction disguised as a feature: the app technically shows the status, but only if the user keeps asking.
The better design inverts this. Instead of the user polling the app, the app proactively tells the user when something relevant changes. A push notification that says "your flight is now delayed 40 minutes" or "your gate changed to B22" is the app doing the watching so the user does not have to. This is the difference between an app the user has to babysit and one they can trust to reach out.
The AirLabs Flight Alert API supports this event-driven design. Rather than requiring your app to repeatedly poll for status, it lets you subscribe to a flight and receive a webhook when something changes. The webhook payload identifies exactly what changed through a changed array listing the updated fields:
{
"changed": [
"dep_gate", "dep_estimated", "status", "dep_delayed", "arr_delayed"
],
"flight": {
"flight_iata": "AA1",
"status": "active",
"dep_delayed": null,
"arr_delayed": 2
}
}Because the payload tells you precisely which fields changed, you can craft a meaningful, specific notification rather than a generic "something updated" — "gate changed" versus "flight delayed" versus "now boarding," each driven by which fields appear in changed. This is what makes proactive notifications feel helpful rather than noisy: they are specific, timely and triggered only by real changes. The webhook model also means your app is not wasting requests polling for changes that have not happened; it is notified only when there is genuinely something to tell the user.
Individually, each of these is a single friction point solved. Together, they form a coherent user journey, and designing them as a set — rather than bolting each on separately — is what makes an app feel considered rather than assembled.
Trace a user through a trip. They open the app and search for where they are going; autocomplete (Suggest) understands their partial, possibly misspelled, possibly non-English input and offers the right destination ranked by popularity. They need a departure airport; location detection (NearBy) has already found the nearest one from their coordinates. Their trip is underway; proactive notifications (Alert) keep them informed of delays and gate changes without them lifting a finger. At each step, the app has done the work the user would otherwise have had to do themselves.
That is the essence of a well-designed experience layer: at every point where the user might have had to work, the app quietly did it for them. None of these patterns is unique or proprietary — they are simply the difference between a flight app that feels effortless and one that feels like a database with a form on top.
A few principles help implement these patterns well, whatever data source sits behind them:
popularity value to order suggestions, so the most likely destination appears first rather than the first alphabetical match.lang where the app is localized, so suggestions come back in the language they are searching in.changed array warrant interrupting the user and which are silent updates.changed fields to say exactly what happened, so the user gets "gate changed to B22," not "flight updated."It is easy to treat search boxes, location detection and notifications as small implementation details to add near the end of a project. Designing them deliberately, as a connected experience layer, is what separates a flight app that users find pleasant from one they merely tolerate. The underlying data can be identical; the experience is where the product is actually differentiated.
The encouraging part is that the building blocks are well-defined. Intelligent search, location awareness and proactive notification are established patterns, and the data to power them is available through documented endpoints — so the effort goes into designing the experience thoughtfully rather than into building the plumbing from scratch.
If you are building the user-facing layer of a flight app — the search, the location awareness, the notifications — the AirLabs API provides the endpoints these patterns need, through a single key.
Our Developer API allows you to create a custom experience for your users and increase the value of your product:
lang, ranked by popularity.distance value, sorted by proximity, within a chosen radius.changed fields when status, gate or times update._fields to keep responses lean for responsive interfaces.You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!
If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.
Explore AirLabs, or create an account instantly and start using API.
Get FREE API Key