Google Flights Unofficial API: Flight Prices Without QPX in 2026

If you went looking for an official Google Flights API in 2026, you already know how that ends: there isn’t one. Google’s only real airfare API was QPX Express, the ITA Software product it acquired and then shut down on April 10, 2018. Google explicitly told developers there would be no public replacement and pointed them at travel partners and ITA’s enterprise licensing instead. So when people search for a “Google Flights unofficial API,” what they actually want is a reliable way to get live flight prices out of the Google Flights frontend without QPX, without a partner contract, and without paying ITA’s enterprise rates. This guide explains how that surface actually works.

Why there is no official API

QPX Express was a paid REST API that returned priced itineraries from ITA’s pricing engine. When Google killed it, the messaging was clear: airfare pricing is commercially sensitive, carriers don’t want it freely redistributed, and Google would keep ITA as a B2B product (now ITA Matrix and the QPX enterprise license) rather than a self-serve API.

What’s left in the open is the consumer-facing Google Flights product at google.com/travel/flights. It is a JavaScript app that renders fares in the browser. There is no API key, no developer console, no documented endpoint — but the browser obviously gets the prices from somewhere, and that “somewhere” is the unofficial API surface everyone ends up using.

What data is actually available

The consumer frontend exposes everything a traveller sees, which is more than most people expect:

• Itineraries: each priced option with total fare, currency, and the cheapest available cabin.
• Legs and segments: operating and marketing carrier, flight number, aircraft type, departure/arrival airports and times, layover airports and durations.
• Stops and duration: number of stops, total trip duration, overnight flags.
• Price calendar / date grid: the lowest fare for each date in a range, which is how the “cheapest dates to fly” view is built.
• Booking handoff token: an opaque token that maps an itinerary to its deep-link booking flow.

What you will not get cleanly is the fare-rules fine print (change fees, fare basis codes) the way QPX returned them. The consumer surface is price-and-schedule oriented, not fare-construction oriented.

How the unofficial API surface works

Google Flights is built on Google’s internal batchexecute RPC mechanism. The page issues POST requests to an endpoint under /_/FlightsFrontendUi/data/... (the path includes versioned RPC identifiers that Google rotates). The request body is not friendly JSON — it’s Google’s nested, positional, array-encoded f.req payload, and the response comes back as a )]}'-prefixed chunked stream of nested arrays rather than named objects.

In practice that means three things:

1. You can’t hand-write the payload from documentation — there is none. You build the search by exercising the real UI and capturing the structure: origin, destination, dates, passenger counts, cabin, and trip type are all positional fields inside that nested array.
2. The response is positional, so you map array indices to fields. Index positions are stable for long stretches but Google does occasionally shift them, which is the main maintenance cost.
3. The date grid is a separate RPC from the itinerary search. The grid call returns one lowest-price-per-day cell across your date window, which is far cheaper than running a full search per date.

Because the surface is a browser RPC and not a static page, a plain curl returns an empty shell. You need a real client context — correct headers, a fresh session, and the rotating RPC identifier from the current app build.

Rate limits and how to live with them

There is no published quota because there is no API. Instead you’re living inside consumer abuse-detection:

• Hammering the RPC endpoint from one IP triggers soft challenges and then 429-style blocks.
• The fix is the usual one: modest concurrency, realistic pacing, and a rotating residential or datacenter IP pool for larger jobs.
• Use the date grid first. Want 60 days of price history for one route? One grid call beats 60 searches and keeps you far under any threshold.
• Cache aggressively. Fares for a given route/date don’t move minute-to-minute; refreshing a route a few times a day is usually enough for monitoring.

A clean output schema

The raw positional arrays are unusable downstream. Normalize each itinerary into something like:

{
  "origin": "SFO",
  "destination": "JFK",
  "departure_date": "2026-07-14",
  "return_date": null,
  "trip_type": "one_way",
  "cabin": "economy",
  "price": 178,
  "currency": "USD",
  "stops": 0,
  "total_duration_minutes": 320,
  "legs": [
    {
      "marketing_carrier": "B6",
      "flight_number": "915",
      "aircraft": "Airbus A321",
      "departure_airport": "SFO",
      "departure_time": "2026-07-14T07:05:00",
      "arrival_airport": "JFK",
      "arrival_time": "2026-07-14T15:25:00",
      "duration_minutes": 320
    }
  ],
  "booking_token": "CjRI...opaque",
  "scraped_at": "2026-06-06T12:00:00Z"
}

For the date grid, a flatter shape works:

{
  "origin": "SFO",
  "destination": "JFK",
  "date": "2026-07-14",
  "lowest_price": 178,
  "currency": "USD",
  "scraped_at": "2026-06-06T12:00:00Z"
}

▶ Try the Google Flights Scraper on Apify — live fares, multi-date price grids, and full leg detail without QPX or an API key. No auth required.

Use cases

• Fare monitoring — track a route over weeks and alert when it drops below a threshold.
• Cheapest-date discovery — pull the full price grid for a flexible traveller or a meta-search feature.
• Competitive pricing — airlines and OTAs benchmark their published fares against Google’s aggregated view.
• Travel content and dashboards — “cheapest months to fly to X” pages are built directly from grid data.
• Corporate travel analytics — measure realized vs. available fares for policy tuning.

Build it yourself vs. a managed actor

Rolling your own is genuinely hard here, harder than a typical scrape. You’re reverse-engineering a positional RPC protocol with no docs, decoding a )]}' array stream, and re-mapping indices every time Google ships a frontend build. Plan on a week to get reliable, then ongoing maintenance whenever positions shift.

A managed actor absorbs that protocol work. You pass origin, destination, dates, and cabin in plain JSON and get the normalized schema above. For a one-off research pull you can hack something together; for anything recurring, the maintenance math favors the managed path.

Common pitfalls

• Currency and locale leakage — the RPC honors the session’s locale, so prices can silently come back in EUR or GBP. Pin currency explicitly.
• Positional drift — when fields look shifted by one, Google changed the array layout. Validate against a known route on every run.
• Date grid vs. search confusion — the grid gives lowest-per-day only, no itinerary detail. Don’t expect leg data from a grid call.
• Booking tokens expire — the opaque token is tied to a session and goes stale; treat it as ephemeral, not a stable key.
• Empty results aren’t errors — some routes genuinely have no service on a date. Distinguish “no flights” from “blocked.”

Wrapping up

There has been no official Google Flights API since QPX Express went dark in 2018, and Google has shown no sign of bringing one back. The unofficial API surface — the consumer frontend’s batchexecute RPC plus the date grid — is the only open path to live flight prices in 2026. It’s workable, but it’s a protocol you maintain rather than a contract you sign. If you just want clean fares without owning that protocol, a managed scraper is the pragmatic Google Flights API alternative.

▶ Open the Google Flights Scraper on Apify — your QPX-free path to flight price data, normalized and ready for ETL. Pay per result.