Google Flights API in 2026: what exists and what it costs

Published August 27, 2026 · Updated October 6, 2026

Short answer: Google shut QPX Express in 2018 and has no public flights API. FlightPowers' Google Flights Live API is the hosted replacement: live Google Flights fares, Google's own low / typical / high price band, a round trip in one request; PRO is $10 for 2,500 searches, about a sixth of SerpApi's price per search (their cheapest plan is $25 for 1,000). Best for price tracking, date scans and AI agents; no booking. The other options are SerpApi and SearchApi (hosted), Duffel and Amadeus (booking APIs), or an open-source scraper.

Google Flights has no public API. Google shut down QPX Express, the last public flight-search API it offered, in April 2018, and what remains is partner access for airlines and OTAs under contract, not for developers who want to query a route and get a price back. Everything sold as a "Google Flights API" since then is a third party reading the public Google Flights site for you. That includes mine. This page lays out the three real options, what one of them returns on a real request, and how to choose.

Is Google Flights still a thing?

Yes. Google Flights is live at google.com/travel/flights and is the site every third-party "Google Flights API", mine included, reads; only the developer API, QPX Express, is gone.

Is there a free Google Flights API?

Not from Google, and the free ways into a hosted one are sized for trying it: 10 searches a month on the free plan of my RapidAPI listing, or 50 a day on the free MCP server with ads after a Google sign-in.

What happened to the official API

QPX Express came out of Google's ITA Software acquisition and let anyone query fares for a few cents per request. Google announced its retirement in late 2017 and switched it off in April 2018. Nothing public replaced it. The demand did not go anywhere, which is why the search results for "Google Flights API" are now a wall of third-party services with similar names.

Why did the niche grow in 2026?

Two self-serve doors closed on top of the one Google shut. Amadeus for Developers Self-Service, the GDS option a solo developer could sign up for without a sales call, was decommissioned on July 17, 2026, by Amadeus' own notice; and Kiwi's Tequila portal offers no registration route for new accounts, only a login for existing ones. Both are quoted and dated, with the commands to check them yourself, in Amadeus Self-Service alternatives you can get into.

The people who picked those services because they were self-serve still need fares. Extraction APIs filled the gap: instead of connecting to a GDS, they read the public Google Flights site and hand back JSON.

What are the three real options?

1. A hosted extraction API. A vendor runs live searches against the public Google Flights site and returns the results as JSON. You trade a per-request fee for not owning the scraping problem. This is what FlightPowers is, and also what SerpApi and SearchAPI sell. The differences that matter: which fields survive the extraction (price context is the big one), how the API behaves when a search fails, and price per request. I compare those honestly, with dated quotes, in the best flight data APIs in 2026.

2. A GDS or booking API. Amadeus, Duffel and the other travel-industry APIs do not touch Google. They sell airline inventory through GDS/NDC channels. You get bookable fares and ticketing, which extraction APIs cannot give you, but the prices are not what a traveler sees on Google Flights, coverage skews to the carriers in the deal, and getting production access involves sales conversations. If your product needs to issue tickets, start there: FlightPowers vs Duffel and vs Amadeus spell out the split.

3. Run a scraper yourself. Open-source projects (the best known is fast-flights on GitHub) parse Google Flights for free. For a personal script this is a fine answer. For anything with users, you now own proxy rotation, consent walls, page redesigns, and the fact that a broken parser returns an empty array that looks exactly like "no flights". That last failure mode is the reason this API reports search status explicitly.

What does a Google Flights API return?

Here is a real request, run on 2026-10-06 through api.flightpowers.com: one way, Berlin to Paris, Tuesday 17 November 2026.

curl -X POST https://api.flightpowers.com/v1/flights/oneway \
  -H "x-api-key: $RAPIDAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from_airport": "BER", "to_airport": "CDG", "departure_date": "2026-11-17", "limit": 5, "currency": "usd"}'

It answered 200 with x-search-status: ok and x-search-results: 5. The first of the five itineraries, as it came back:

{
  "price_range_in_relation_to_other_periods": "typical",
  "price_insights_low": 45,
  "price_insights_high": 105,
  "from_airport": "Berlin (BER)",
  "to_airport": "Paris (CDG)",
  "departure_date": "2026-11-17",
  "price": "$59",
  "price_as_number": 59,
  "duration": "1 hr 55 min",
  "duration_seconds": 6900,
  "buy_link": "https://www.google.com/travel/flights?tfs=GjwSCjIwMjYtMTEtMTciIAoDQkVSEgoyMDI2LTExLTE3GgNDREcqAlUyMgQ1MTQ5agUSA0JFUnIFEgNDREdCAQFIAZgBAg&curr=usd",
  "airline": "easyJet",
  "stops": 0,
  "stops_info": [],
  "departure_description": "6:10 AM on Tue, Nov 17",
  "arrival_description": "8:05 AM on Tue, Nov 17"
}

Fares move, so yours will differ. The three fields that separate a useful extraction API from a basic one:

1. price_range_in_relation_to_other_periods: Google's own verdict on the fare, low, typical or high. Here it is typical.
2. price_insights_low / price_insights_high: the band Google shows travelers under the price, $45 to $105 for this route and date. A $59 fare sits in the lower part of it.
3. buy_link: a deep link that reopens this exact itinerary on Google Flights, ready to book.

The verdict is what turns a price feed into "book now or wait" logic. Without it you need months of your own price history before you can judge a fare. With it, a fare alert or an agent can judge the first fare it ever sees. The band is Google's, so on thin routes and far-out dates it can be missing; treat a missing verdict as "unjudged", never as "not low".

How do you tell an empty result from a failed search?

The most dangerous answer a search API can give is 200 []: success, no rows. It can mean there are no flights, or that the search timed out, or that the parser found nothing on a page full of fares. A fare alert that cannot tell these apart either reports "no flights" when it should retry, or stores a gap as a fact.

So every response carries an X-Search-Status header. ok is a complete search. degraded or partial means some of the work failed, and the result must not be stored as "this route has nothing". X-Search-Results gives the row count without parsing the body. On the MCP servers the same value arrives as search_status inside the tool result. The full taxonomy is in handling empty flight search results.

REST or MCP?

Both read the same live data with the same key, and the price per search is the same.

REST is a POST endpoint you call from any language: a web app, a mobile backend, a cron job that scans fares. It takes one date pair per request, so a month of dates is a month of requests, sent in parallel within your plan's rate limit.

MCP (Model Context Protocol) is a server URL you add to Claude, Cursor or ChatGPT, and the model calls its tools when it needs a fare. Those tools take a date range and a list of destination airports in one call and expand them server side.

{
  "mcpServers": {
    "flights": {
      "url": "https://flights.flightpowers.com/mcp",
      "headers": { "x-rapidapi-key": "YOUR_KEY" }
    }
  }
}

Or drop the headers block: the same URL answers a credential-less client with a sign-in, and you paste your key once on the page that opens instead of into the file. If you are building an agent, start with MCP; if you are building a product with a UI, start with REST. The AI travel agent guide shows both in context.

What can't a Google Flights API do?

These are data APIs. They replace the shopping half of a travel stack, not the booking half. A Google Flights API cannot issue tickets, create a booking or a PNR, hold inventory, take a payment, or sell seats and bags. What it can do: return the fare a traveler would see right now with Google's judgement of it, and hand them a link to buy it on Google Flights.

It is the right tool for fare alerts, price calendars, trip planners, market analysis and AI agents that advise on when to book. It is the wrong tool if your flow ends with "confirm booking" inside your own product; then you need Duffel or a GDS.

What does it cost?

Plans as listed on RapidAPI, re-read on 2026-09-28 by a script that fails loudly when a number drifts:

BASIC needs no card and verifies a key; it is too small to judge the data on. Hotels are a separate subscription on the same RapidAPI key. Current numbers always live on /pricing.

How do you get a key?

Subscribe on the RapidAPI listing, pick a plan, and the key is on the page. There is no application and no sales call. If you already use any API on RapidAPI, it is the same key. The step-by-step version is how to get a Google Flights API key.

How to choose, in three questions

1. Do you need to issue tickets? GDS/booking API. Nothing else will do it.
2. Do you need the prices travelers actually compare? Google Flights data, which means an extraction API or your own scraper. Then check which one returns Google's price band and verdict, because without them you are building a price history before you can say whether a fare is good.
3. Is this a product or a weekend script? Products need the failure-mode contract (what does an empty array mean?) and a rate limit that supports date scans: a 30-date scan is 30 requests, and a 10-a-minute limit turns it into a three-minute wait. Scripts can use anything, including free scrapers.

The machine-readable contract is public: OpenAPI spec, llms.txt, full reference.

Related

• How to get real-time Google Flights data: the full walkthrough with paste-and-run code
• How to get a Google Flights API key: the two-minute setup
• The best flight data APIs in 2026: the comparison, bias disclosed
• Handling empty flight search results: why 200 [] is dangerous
• Amadeus Self-Service alternatives you can get into: what replaced the self-serve GDS door
• MCP servers: the same data as tools for Claude, ChatGPT, Cursor, or any MCP client
• Get a key on RapidAPI: free tier included (10 requests/month, hard cap: verifies your key, doesn't evaluate)