Google Flights API: Get Live Data (2026)

If you've ever opened google.com/flights and thought "I wish I could pull this data into my app", you're not alone. Google Flights has the cleanest fare ranking, the best airline coverage, and the fastest price refresh on the web — and until 2018, it even had a public developer API called QPX Express.

That API is gone. But the data isn't out of reach. This tutorial shows exactly how to pull live Google Flights data — real-time fares, route options, price calendars, and bookable partner links — through a modern helper API, with full working code in Node.js, Python, and cURL.

"Live Google Flights data" in this guide means five things: the current fare for a route, the airlines offering it, layover and duration details, cheapest dates across a calendar range, and a bookable link that routes users to the airline or OTA to complete the purchase. Every one of those is available as structured JSON in 2026 — you just need to know which endpoint to hit and how to authenticate. By the time you finish reading, you will be able to get live data for any route, any date, and any cabin class, in a few lines of code.

Why you need a helper API for Google Flights#

Google Flights itself is a consumer website. There is no api.google.com/flights endpoint and no developer key you can request. Google has intentionally kept this a closed surface since shutting down QPX Express in 2018 — open access would undercut its own position in travel metasearch.

That leaves developers with three options:

1. Scrape google.com/flights directly. Technically possible, but Google's anti-bot protections (device fingerprinting, behavior profiling, CAPTCHAs, rotating DOM selectors) make this a full-time infrastructure problem, not a weekend project.
2. Switch to a different data source — Duffel, Amadeus, Kiwi. These are excellent APIs, but the ranking, filter logic, and visible prices are not what google.com/flights shows. For SEO tools, price trackers, and comparison content, that difference matters.
3. Use a Google Flights helper API — a managed service that does the proxying, anti-bot handling, and response shaping for you, and returns the actual Google Flights results as JSON.

This guide focuses on option 3, which is the fastest way to ship if you specifically need Google Flights data.

The Google Flights API we recommend#

The DataCrawler google-flights2 API is distributed on RapidAPI. It exposes 12 endpoints that cover every major surface of google.com/flights — one-way search, round-trip, multi-city, price calendar, price graph, and the partner-checkout redirect flow Google Flights itself uses.

How the Google Flights API works behind the scenes#

When you call the DataCrawler Google Flights API, your request is forwarded to google.com/flights through a managed proxy and browser automation layer. The service handles the hard infrastructure work that makes scraping Google painful at scale: residential IP rotation, TLS fingerprinting that matches real browsers, CAPTCHA solving, and DOM-change resilience when Google ships UI updates. You never see any of that — you get clean JSON back.

Because the data is aggregated live for each call, the fares you get match what a human visitor would see in the same browser session on the same date. That is what makes this a real Google Flights helper API and not just another flight search API — other providers (Duffel, Amadeus, Kiwi) source their data from GDS feeds or direct airline connections, which is similar to Google's inventory but ranked differently and sometimes priced differently. For tools where "what Google shows" is the whole point — SEO content, price monitoring, affiliate funnels — only a Google-Flights-sourced data API gives you the right numbers.

Quickstart: your first Google Flights API call#

Step 1 — Get a RapidAPI key#

1. Create a free account at rapidapi.com.
2. Visit the DataCrawler Google Flights API listing.
3. Click Subscribe to Test and pick the BASIC plan (free, 150 requests/month — enough to validate the integration).
4. Copy your X-RapidAPI-Key from the code-snippets panel.

Step 2 — Send a test request#

The simplest working call is a one-way search. In cURL:

curl --request GET \
  --url 'https://google-flights2.p.rapidapi.com/api/v1/searchFlights?departure_id=LAX&arrival_id=JFK&outbound_date=2026-05-10&adults=1&travel_class=ECONOMY&currency=USD' \
  --header 'X-RapidAPI-Host: google-flights2.p.rapidapi.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY'

You'll get back a JSON envelope:

{
  "status": true,
  "data": {
    "itineraries": {
      "topFlights": [
        {
          "price": 198,
          "stops": 0,
          "departure_time": "2026-05-10T07:30:00",
          "arrival_time": "2026-05-10T15:55:00",
          "airlines": ["Delta"],
          "booking_token": "CjRIR2d0..."
        }
      ]
    },
    "next_token": "CjRIR2d0..."
  }
}

That's a live Google Flights result — the same listing a human visitor would see for LAX → JFK on that date, in the same order Google ranks them.

The 12 endpoints explained#

The Google Flights API surfaces the full behavior of google.com/flights across these endpoints:

If you're building a full Google-Flights-style UI, the pattern is usually: searchAirport for the origin/destination autocomplete → getCalendarPicker to show the cheapest dates → searchFlights on date selection → getBookingURL when the user clicks a result.

Node.js example — round-trip search#

// npm install node-fetch
import fetch from "node-fetch";
 
const RAPIDAPI_KEY = process.env.RAPIDAPI_KEY;
const HOST = "google-flights2.p.rapidapi.com";
 
async function searchFlights({ from, to, outbound, ret }) {
  const url = new URL(`https://${HOST}/api/v1/searchFlights`);
  url.searchParams.set("departure_id", from);
  url.searchParams.set("arrival_id", to);
  url.searchParams.set("outbound_date", outbound);
  if (ret) url.searchParams.set("return_date", ret);
  url.searchParams.set("adults", "1");
  url.searchParams.set("travel_class", "ECONOMY");
  url.searchParams.set("currency", "USD");
 
  const res = await fetch(url, {
    headers: {
      "X-RapidAPI-Key": RAPIDAPI_KEY,
      "X-RapidAPI-Host": HOST
    }
  });
 
  if (!res.ok) throw new Error(`Google Flights API ${res.status}`);
  const { data } = await res.json();
  return data.itineraries.topFlights;
}
 
const flights = await searchFlights({
  from: "SFO",
  to: "LHR",
  outbound: "2026-06-15",
  ret: "2026-06-25"
});
 
for (const f of flights.slice(0, 5)) {
  console.log(`$${f.price} · ${f.airlines.join("/")} · ${f.stops} stop(s)`);
}

Python example — cheapest dates via price calendar#

import os
import requests
 
HOST = "google-flights2.p.rapidapi.com"
HEADERS = {
    "X-RapidAPI-Key": os.environ["RAPIDAPI_KEY"],
    "X-RapidAPI-Host": HOST,
}
 
def cheapest_dates(from_code, to_code, start, end):
    r = requests.get(
        f"https://{HOST}/api/v1/getCalendarPicker",
        headers=HEADERS,
        params={
            "departure_id": from_code,
            "arrival_id": to_code,
            "outbound_date": start,
            "start_date": start,
            "end_date": end,
            "adults": 1,
            "trip_type": "ONE_WAY",
            "currency": "USD",
        },
        timeout=15,
    )
    r.raise_for_status()
    return r.json()["data"]
 
cal = cheapest_dates("JFK", "CDG", "2026-08-01", "2026-08-31")
for day in cal[:5]:
    print(day["date"], "→", day["price"])

Two things worth noting:

• Set a real timeout. Google Flights responses average ~5–6 seconds because the API is aggregating live data on each call. Don't set a 1-second timeout and wonder why things fail.
• Cache aggressively. Popular routes don't need to hit the API on every page view. A 10-minute cache per (origin, destination, date) tuple will cut your request count by 10–100x with almost no user-facing staleness.

What you can build with the Google Flights API#

The most successful projects built on a live Google Flights data feed tend to fall into one of five categories, and each one leans on a slightly different endpoint mix. Understanding which pattern fits your product is more useful than memorizing the full endpoint list.

Price-drop alerts schedule searchFlights calls for a watchlist of routes and notify users when a fare crosses their threshold. These are cheap to run because each user only needs one or two calls per day per watched route. With the free BASIC tier you can run a personal price tracker for a handful of routes; on PRO you can serve thousands of users. The key to keeping costs low is batching: one call serves all users watching the same route.

Cheap-date finders render a month calendar with the lowest fare per day using getCalendarPicker — the exact feature Google Flights itself uses under the date picker. This is one of the highest-converting surfaces in travel because it answers the user's real question: "When is it cheapest to go?" A single calendar call covers up to 60 days, which makes this endpoint extremely efficient per dollar.

Travel content and affiliate sites build SEO pages for "cheap flights from X to Y" and embed live prices via searchFlights, with affiliate booking redirects wired up through getBookingURL. This is the core use case for content creators in 2026 — organic traffic from search plus a revenue share on every booking that clears.

Internal corporate travel tools use the Google Flights API as a policy and pre-approval layer. Before an employee books, the tool fetches the live fare and flags whether it falls within policy. Agency back-offices use the same flow for price checks against GDS quotes.

Research and analytics teams pull historical fare snapshots on key routes for journalism, market analysis, and long-term trend reports. Because the API returns the Google-ranked view, the data is the closest thing to a public record of what consumers were being shown on any given day.

Pricing — what each tier actually gets you#

Every endpoint call — search, calendar, price graph, booking URL — counts as one request. With sensible caching, the PRO tier is the right starting point for most production apps; MEGA kicks in once you're serving real affiliate traffic and need overage protection.

Limits and caveats to plan for#

Common errors and how to handle them#

A few issues come up often enough that they are worth planning for before you ship. The good news is that each one has a well-understood fix, so handling them cleanly is a matter of wiring the right response code to the right behavior.

429 Too Many Requests means you have hit the per-minute rate cap on the BASIC tier (250 per minute) or the monthly quota on any tier. Check the Retry-After header and wait that long before retrying. If you are hitting the monthly quota frequently, upgrading one tier up is almost always cheaper than building a queueing system.

Timeouts happen most often because a searchFlights call is aggregating live data and that can take up to ten seconds on cold queries. Set a 15-second client timeout at minimum, and retry once on a gateway timeout before surfacing an error. Users tolerate a spinner better than a failure message.

Empty topFlights array usually means the route does not have direct inventory on the date you queried, not that the API failed. Fall back to searchMultiCityFlights with connecting options, or suggest nearby airports using searchAirport. Returning "no results" to the user is almost never the right answer — the live data exists, you just need to widen the search.

Invalid airport code returns a structured error rather than an empty result. Always validate user input through searchAirport before submitting a search. It is one extra call but it eliminates an entire class of confusing failures.

Final checklist before you ship#

1. Auth works — your X-RapidAPI-Key header returns 200 on /api/v1/checkServer.
2. Airport codes validated — searchAirport on user input before submitting a search.
3. Caching in place — at minimum, a 5–10 minute in-memory cache keyed by (origin, destination, date, pax, class).
4. Timeouts set — a 15-second client timeout accounts for the API's aggregation latency.
5. Error handling — retry once on 5xx, respect Retry-After on 429, surface a friendly message on 4xx.
6. Booking redirect logged — if you're doing affiliate, persist the booking_token and the outbound click for attribution.

Once those six boxes are ticked, you've got a production-grade Google Flights integration — the same live data users see on google.com/flights, served through your own UI, with none of the scraping infrastructure headaches.

The state of flight data APIs in 2026 is healthier than at any point since Google retired QPX Express. The helper-API category — services that return Google Flights data as JSON on demand — has matured enough that solo developers, small travel startups, and even mid-sized content sites can get live fare data at a price point that makes sense for their traffic. You no longer need a GDS contract, a scraping farm, or an airline partnership to build a genuinely useful flight product. Pick a helper API, read the endpoint list once, cache sensibly, and you will be shipping working flight search within an afternoon.

Related reading#

• Browse more data & analytics APIs — scraping, enrichment, and market-data providers in the same helper-API family.
• New to integrating third-party APIs? Our OpenAI API guide walks through auth, first request, and error handling end-to-end.
• Choosing between providers? The Stripe vs PayPal vs Square API comparison uses the same pros/cons + pricing-table format as this guide.