How Flight Intelligence Works
Flight Intelligence is destination.com's AI reasoning layer for flight search. It doesn't replace booking — it helps you decide which flight to book. This page explains exactly how it works, where the data comes from, and how we make money.
Where the data comes from
Live fare data is provided by Travelpayouts, which aggregates inventory across 800+ airlines and major OTAs including Expedia, Trip.com, Kiwi, Booking, and Priceline. The cache refreshes approximately every 30 minutes. When you click Book, you're handed off to the partner displaying that fare, and you complete payment there.
For airline policies (baggage fees, change rules, refund terms), we pull from each airline's official website. Policies are summarized as “standard fare-class behavior” and you should always confirm exact terms at the booking step.
How ranking works
Recommendations are sorted by total price ascending — base fare plus any mandatory ancillaries we can identify (carry-on fees on carriers that charge them, payment surcharges where applicable). Tie-breakers, in order: shorter total elapsed time, fewer stops, longer minimum connection time on multi-leg routes.
The ranking algorithm is a pure function in our codebase. It does not take partner commission rate as an input. It cannot be configured to boost any specific partner. This is enforced at the code level, not as a policy.
How we make money
destination.com is a participant in the Expedia Group Travel Creator Program via Partnerize. When you book through a partner link, the partner pays us a commission funded from their marketing budget. This does not change the price you pay.
Commission rates vary by partner. The Flight Intelligence ranking algorithm is deliberately blind to commission rate — we rank the flight that's best for you, regardless of who pays us more for the click.
What the AI does and doesn't do
What it does
- Ranks flights by price and itinerary quality
- Explains trade-offs (layover length, total travel time, connection risk)
- Summarizes baggage and change-fee policies from airline sources
- Surfaces ancillary fees that aren't visible in headline fares
What it doesn't do
- Hold or reserve seats — fares can change between search and booking
- Process payment — booking happens on the partner site
- Recommend tactics that violate airline contracts of carriage, including hidden-city ticketing, throwaway ticketing, or back-to-back ticketing
- Provide legal, immigration, or visa advice
Hidden-city routes
The Hidden-city Routes tab surfaces layover-arbitrage patterns — booking a one-stop fare and deplaning at the connection when it's cheaper than a direct ticket to that connection city. These are educational: we describe the pattern and estimate the typical savings; we do not book, price-verify, or handle any part of the transaction for you.
Read before you try any of this:
- Missed connections cost you the rest of the trip. If your first leg is delayed and the airline rebooks you onto a later flight, the itinerary you actually planned to fly (the layover) may no longer exist as a valid routing — you can end up rerouted through a different hub entirely.
- Checked bags follow the ticket, not the passenger. Bags go to the final ticketed destination. Carry-on only.
- One-way only. If you no-show a leg on a round-trip fare, most carriers cancel every remaining segment, including your return.
- Airline contracts prohibit it.This isn't illegal for travelers, but it violates most contracts of carriage. Airlines have historically responded with frequent-flyer account closures, ticket invalidation, and (rarely) legal action against repeat offenders.
We show the pattern and the risks side by side. Whether it's worth the trade is a decision only you can make for a specific trip.
Route optimizer
The Route optimizer tab answers a specific question: given 3–8 cities you want to visit, in what order should you fly them to minimize the total fare bill? User-supplied city order is discarded — the algorithm treats them as an unordered set and finds the visit sequence with the lowest cached total.
How the algorithm works. We fetch the cheapest cached one-way fare for every directed city pair across the requested months (default: the next two months) from Travelpayouts. That gives us a directed cost matrix. For 5 or fewer cities we brute-force every permutation — 5! = 120 orderings, trivial to score. For 6–8 cities we run a nearest-neighbor construction from every starting city, then apply 2-opt local search to each candidate and keep the top three distinct orderings by total cost. 2-opt reverses contiguous sub-paths whenever the swap reduces the total; it typically converges within a handful of sweeps and is well-studied to land within a few percent of optimal on Euclidean-like TSPs, which airfare matrices approximate.
Why not exact solving.Held-Karp dynamic programming would guarantee optimality but runs in O(n² · 2ⁿ). At n=8 that's ~16,000 states — still fine — but we chose 2-opt because it degrades gracefully if we later raise the cap, and because a few percent of theoretical optimum sits well inside the noise of month-scoped fare estimates. If we ever start pricing to the exact day, revisit this choice.
Why we cap at 8 cities.Two reasons. First, edge fan-out: 8 cities is 8 × 7 = 56 directed pairs × up to 3 months = 168 upstream fetches at the ceiling, which fits our 30-second endpoint budget with concurrency 6. A ninth city pushes it to 216 pairs. Second, ordering quality: nearest-neighbor + 2-opt from every start still explores the full solution neighborhood at n=8; past that we'd want a full Held-Karp or genetic algorithm to preserve tight bounds.
How carrier codes are reported.Each edge is priced at the cheapest fare our cache saw for that pair in that month, and the winning fare's airline IATA code (FR = Ryanair, LH = Lufthansa, etc.) is passed through to the results panel with the airline's full display name. If the cache didn't return an airline for the winning row, the edge is shown with price and month only — never a fabricated carrier.
Dates are month-scoped estimates.The Route optimizer picks a representative month per hop, not a specific day. Cross-hop chronological consistency is the traveler's job at booking time — the results panel shows the recommended month per edge, and the CTA hands you off to the partner where you pick exact dates. A future v2 pass may enforce chronological ordering across the trip window; for now, treat the output as ordering + cost guidance.
Deals detector
The Deals detector tab answers a specific question: given my origin and a month or two of dates, which cached fares are unusually cheap right now? User-supplied destinations are optional — leave the field blank and we scan a curated top-40 list of destinations we cover editorially.
How the algorithm works.For every (origin, destination, month) cell in the scan, we pull the recent fare rows Travelpayouts has cached — up to 30 per cell, sorted by price. We compute the rolling median across those rows, then check whether the cell's lowest observed fare sits at least the configured savings threshold (default 25%) below the median. Cells with fewer than three rows are suppressed — a “savings” against a two-sample baseline is noise, not signal. Surviving deals are ranked by savings percentage (largest first), ties broken by lowest price, and the top five are surfaced.
Why “rolling median” and not a strict 30-day window. Travelpayouts does not expose historical price snapshots we can align to calendar days. What it does expose is the current cache of every fare it has surfaced for a pair-month — a broad enough sample on major pairs (typically 15–20 rows) to compute a defensible median. We chose that over a fake 30-day window that would require us to fabricate historical data. For thin routes with fewer than three rows we suppress the cell entirely rather than report a low-confidence deal.
Why we cap at 40 destinations and 3 months. Ceiling scan is 40 × 3 = 120 pair-month fetches at concurrency 8, which fits the 25-second endpoint budget with room for the reasoning prose pass. A wider scan would push us past budget and start dropping cells silently — better to reject the request than return an incomplete answer.
Flexibility
The Flexibility tab answers a specific question: given my window from X to Y and a desired nights range, what's the cheapest way to fit that in, and what does my day-of-week flexibility actually cost me? It's the tab to reach for when your calendar is negotiable and you want to see the price impact of every degree of freedom.
How the algorithm works. We enumerate every valid (depart, return) pair inside the window whose spread lands in the min/max nights range, and price each pair via Travelpayouts. We then report three answers from the priced set: the cheapest combo overall, the cheapest combo with a Saturday or Sunday departure, and the departure day-of-week whose average priced combo beats the worst DOW average (with the percentage savings). Sonnet writes short prose on the cheapest and weekend combos; the numbers and rank are code-set.
Why we cap at 60 combos.That's enough to cover a two-week window with a five-night nights range, or a one-month window with a smaller nights range — the usual shape of “when should I take this trip?” questions. Larger requests are rejected with a message asking the traveler to narrow the window or the nights spread rather than being partially priced.
Day-of-week uses the mean, not the median.Weekly seasonality is generally symmetric across the priced combos, so the mean is a fine estimator and produces a stable ordinal ranking (which day is cheapest, on average). If a single Wednesday combo is an outlier, it doesn't flip the answer.
Maximum nights = 30.Travelpayouts' round-trip cache rejects itineraries longer than 30 days, and the Flexibility tab surfaces that limit at input validation time rather than letting the upstream failure bubble up as a misleading error.
Known data gaps
Travelpayouts coverage is comprehensive but not exhaustive. A few carriers are systematically under-indexed or absent:
- Ryanair typically blocks aggregator access
- Wizz Air, Southwest, Allegiant coverage varies by route
- Some regional and charter operators are not included
When we suspect an LCC operates a route that isn't in our cache, we flag it and recommend you check the carrier directly.
Questions or concerns
Email hello@destination.com.