How a flight meta search engine works behind the scenes. The four architectural layers of a flight comparison aggregator — fare aggregation, aviation reference data, live tracking and booking redirect — and how AirLabs supplies the aviation data layer.
To a traveller, a flight meta search engine looks simple — enter dates and cities, see a ranked list of flight options across many airlines and booking sites, click one and be redirected to complete the purchase. The category has made this pattern feel routine to travellers worldwide. Behind the interface, however, sits one of the more architecturally interesting products in travel technology, because a meta search engine is not the source of any of its data. It is the aggregation layer above other people's data, and its value is entirely in how well those pieces fit together.
Meta search is different from an Online Travel Agency (OTA) and different from a Global Distribution System (GDS). An OTA sells the ticket itself and holds the customer relationship through the purchase. A GDS provides the inventory and reservation backbone that airlines and OTAs both plug into. A meta search engine sits above both — it does not sell tickets, it does not run the reservation system, and it typically does not have a direct commercial relationship with the airline whose fare it displays. Its business is finding, ranking and presenting options that live in other systems, then handing off to the seller when the traveller commits.
This guide is about the backend architecture — the data layers a working meta search engine assembles, what each layer requires, and where a flight data API like AirLabs sits within it. It is honest about scope: AirLabs supplies the aviation reference and operational data layer, not the fare aggregation or booking layers. Understanding this split is the first step to building a meta search engine that works — because pretending any single provider covers everything is the most common early-stage mistake.
"A meta search engine's product is not data — it is the arrangement of data. Fares, schedules, airport codes, aircraft types, live status — each comes from a different source, each has its own update cadence, each fits together only if you get the reference layer right. The reference layer is boring and invisible until you build without it, at which point nothing joins."
A flight meta search engine is best understood as four layers stacked on top of each other, each solving a different problem, each typically served by a different provider or set of providers.
Layer 1 — Fare aggregation. This is the price and availability layer — actual fares for actual routes on actual dates, sourced from airlines directly (via their APIs or NDC feeds), from consolidators, from OTAs, or from specialized fare aggregation providers. It answers "what does it cost to fly from A to B on this date." AirLabs does not operate at this layer.
Layer 2 — Aviation reference data. This is the layer that turns "New York" into "JFK, LGA and EWR," turns "American Airlines" into IATA code "AA," and knows that a route from LHR to JFK is operated by BA, AA, VS, DL and JL. This layer is the scaffolding on which the fare layer hangs — without it, every fare result is a set of codes users cannot search on and results cannot be filtered or grouped meaningfully. AirLabs operates at this layer through the Airports Database, Airlines Database, Cities Database, Routes Database and Name Suggestion API.
Layer 3 — Operational data and tracking. This is the layer that answers "when does this actual flight depart," "is it currently delayed," "what aircraft is operating it," and — after booking — "where is our customer's flight right now." Meta search engines increasingly surface this data to differentiate themselves and to support the post-booking experience their affiliates depend on. AirLabs operates at this layer through the Real-Time Flights API, Schedules API, Flight Information API, Flight Delays API and Flight Alert API.
Layer 4 — Booking redirect and commercial layer. When a traveller clicks a result, meta search hands off — via a deep link, an affiliate redirect, or an embedded booking flow — to the airline or OTA that actually holds the reservation. This layer is commercial (affiliate agreements, referral fees, click-out tracking) rather than technical. AirLabs does not operate at this layer.
The clean statement of scope: AirLabs supplies layers 2 and 3 — aviation reference data and operational data — and does not supply layers 1 and 4. The other layers come from other providers, and a working meta search engine combines them intentionally.
Reference data is the least visible and most under-appreciated layer of a meta search engine, because it does not appear in fare results directly — it appears in the machinery around them. Almost every user-facing feature of a meta search engine depends on it.
The user types "London" into an origin field and expects an autocomplete list showing London-area airports — LHR, LGW, STN, LTN, LCY, SEN — with plain-language names, city association and geographic proximity. That interaction is the Name Suggestion API and the Airports Database at work:
GET https://airlabs.co/api/v9/suggest?q=London&api_key={KEY}
{
"airports": [
{"iata_code": "LHR", "name": "Heathrow", "city": "London", "country_code": "GB", "lat": 51.4706, "lng": -0.461941, "timezone": "Europe/London"},
{"iata_code": "LGW", "name": "Gatwick", "city": "London", "country_code": "GB", "lat": 51.1481, "lng": -0.190278, "timezone": "Europe/London"},
{"iata_code": "STN", "name": "Stansted", "city": "London", "country_code": "GB", "lat": 51.885, "lng": 0.235, "timezone": "Europe/London"}
],
"cities": [
{"city_code": "LON", "name": "London", "country_code": "GB", "timezone": "Europe/London"}
]
}The user filters results by airline — "hide low-cost carriers" or "only Star Alliance" or "only IATA-registered airlines" — and expects the filter to work correctly, which requires structured airline data with iata_code, icao_code, country_code, iata_prefix and fleet attributes from the Airlines Database.
The user asks "does anyone fly direct from Tallinn to Faro?" and expects an answer even before a fare search runs, which requires knowing the airline route network — the Routes Database with pairs of dep_iata and arr_iata operated by each carrier. This layer prevents empty fare searches by ruling out routes that no carrier operates at all.
The user searches "flights from New York to Los Angeles" and expects the engine to consider all New York airports and all Los Angeles airports as origin and destination candidates. This requires multi-airport city resolution — the Cities Database and the NearBy API for finding all airports within a metropolitan area:
GET https://airlabs.co/api/v9/nearby?lat=40.7128&lng=-74.0060&distance=100&api_key={KEY}Each of these is a small interaction on the interface. Together they are the reference layer that makes the whole product feel intelligent rather than mechanical.
A meta search engine's user relationship does not end at the click-out. Increasingly, users expect to return to the engine that helped them find the flight — for status checks, delay updates, gate information and the reassurance that comes with knowing where their trip stands.
The Flight Information API turns a booked flight identifier into a full status view:
GET https://airlabs.co/api/v9/flight?flight_iata=BA117&api_key={KEY}
{
"flight_iata": "BA117",
"dep_iata": "LHR",
"arr_iata": "JFK",
"dep_time": "2026-07-22 10:00",
"dep_estimated": "2026-07-22 10:47",
"dep_terminal": "5",
"dep_gate": "A22",
"arr_time": "2026-07-22 13:15",
"arr_estimated": "2026-07-22 14:02",
"status": "active",
"delayed": 47,
"aircraft_icao": "B77W"
}For active tracking during the flight, the Real-Time Flights API provides live position; for proactive alerts on status changes, the Flight Alert API subscribes via webhook to the specific flight number. Between them, they support a post-booking experience the traveller feels — and that keeps them returning to the meta search engine rather than bouncing to airline sites for updates.
Being clear about scope makes the architecture easier to build. AirLabs is a flight data API. It does not include:
For the fare and booking layers of a meta search engine, the market offers several categories of provider. Direct airline NDC APIs give the richest data but require an integration per airline. Consolidators and fare aggregation platforms provide broader coverage through one integration but with different data quality trade-offs. GDS-connected providers offer the traditional path with the widest coverage but the most complex commercial arrangements. A meta search engine typically picks one or more of these based on its target market, then layers the AirLabs reference and operational data on top.
For the booking redirect layer, most meta search engines operate on affiliate agreements with the airlines or OTAs whose fares they surface. This is a commercial layer rather than a technical one.
A practical meta search engine architecture, laid out as data flow:
Every step in this flow has clear ownership. The fare aggregator owns the pricing. AirLabs owns the reference and status. The airline or OTA owns the reservation. The meta search engine owns the assembly.
A common failure mode in early meta search products is undervaluing the reference data layer, on the assumption that airport codes and airline names are trivial static data anyone can build. In practice, keeping this data accurate is where the operational cost lives — new low-cost carriers launching, airports opening and closing, IATA and ICAO codes being reassigned, airlines rebranding, routes changing seasonally. A meta search engine relying on a stale reference set will show fares from airlines it cannot name correctly, offer routes that no longer operate, and fail to expand New York searches to include an airport that opened last year.
The reference layer is not glamorous, but its quality directly affects search relevance, filter accuracy and the perceived intelligence of the product. Sourcing this layer from a maintained, versioned API is what lets a small team focus on the fare aggregation and ranking logic that actually differentiates their product, rather than spending engineering time on updating airport code tables.
_fields on high-volume endpoints. For autocomplete and result-page joins, requesting only the specific fields you display keeps responses small and interactions fast.cs_flight_iata and cs_airline_iata fields that identify the operating carrier — surfacing this clearly in your interface prevents duplicate results and confused users. Our Codeshare Flights guide explains the pattern in detail.If you are building a flight meta search engine, a flight comparison site or a fare aggregator, the aviation data layer — reference data plus operational status — is one of the four architectural pieces you need. AirLabs supplies that layer through documented REST endpoints and a single API key, so you can focus your engineering effort on the fare aggregation logic, ranking algorithms and user experience that actually differentiate your product.
Our Developer API allows you to create a custom experience for your users and increase the value of your product:
_fields for lean, targeted responsesYou 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