Google Flights Scraper & Flight Legs

Scrape Google Flights itineraries for any route and date — the same fare list a standard Google Flights scraper returns — plus every connecting flight broken out leg by leg: real aircraft type, real legroom, real flight numbers, real layover airports and minutes, real carbon emissions, and the bag allowance Google shows before you book. Built for anyone who has to approve or filter an itinerary, not just its price: a 52-minute connection at a busy hub, a 28-inch-pitch regional jet, or a fare with zero checked bags.

What this Google Flights scraper does

This actor queries google.com/travel/flights for a departure airport, arrival airport, and date (one-way, round-trip, or multi-city) and returns every itinerary Google shows — price, duration, airline, and stops — the same core data any Google Flights scraper API returns. On top of that base fare list, it reads the itinerary's own connection and per-leg data straight out of the response Google already sends, so you get:

• Real per-leg detail — carrier code, flight number, aircraft type (e.g. "Airbus A321neo", not a generic placeholder), legroom in inches, and the full origin/destination airport name for every leg of a connecting itinerary.
• Real layovers — every connecting airport, city, and exact connection time in minutes, plus a filter to drop itineraries with a connection that's too short to make or too long to be worth it.
• Real carbon emissions — the actual kilogram figure and percentage vs. the typical emissions for that route, not a placeholder value.
• Bag allowance — carry-on and checked bags included in the quoted fare.
• Next-day arrival flag — flights that land a calendar day later than they depart, useful for red-eyes and long-haul connections.

Key features

• 🛫 One-way, round-trip, and multi-city search
• 💺 Cabin class, passenger count (adults/children/infants), and currency/locale control
• 🛑 Stop-count filter plus a connection-time filter (minLayoverMinutes / maxLayoverMinutes) that drops itineraries whose layovers are too tight or too long
• 🦵 Per-leg aircraft, legroom, flight number, and airport detail — not just a route summary
• 🌱 Real carbon emissions per itinerary, compared against the route's typical figure
• 🧳 Carry-on and checked bag counts as quoted with the fare
• 💰 Max-price filter and configurable result cap
• 🛡️ Residential proxy by default (Google blocks datacenter IPs on this endpoint)

Input example

{
  "departureIATA": "LAX",
  "arrivalIATA": "JFK",
  "departureDate": "2026-09-15",
  "adults": 1,
  "seatclass": "1",
  "stops": "2",
  "currency": "USD",
  "hl": "en",
  "gl": "us",
  "maximum": 30,
  "includeLegDetails": true,
  "includeLayovers": true,
  "minLayoverMinutes": 45,
  "maxLayoverMinutes": 240,
  "includeBaggageAllowance": true,
  "includeCarbonEmissions": true,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

minLayoverMinutes / maxLayoverMinutes only affect connecting itineraries — nonstop flights are never dropped by this filter. Bag-allowance parsing only works reliably when hl is en (English); every other field is unaffected by locale.

Output example

Every dataset row keeps the base actor's original fields (is_best, type, price, currency, duration_minutes, airline, departure_airport, arrival_airport, raw_flight_data) and adds:

{
  "is_best": false,
  "type": "One way",
  "price": 139,
  "currency": "USD",
  "duration_minutes": 540,
  "airline": "Frontier",
  "departure_airport": "LAX",
  "arrival_airport": "JFK",
  "legs": [
    {
      "carrier_code": "F9",
      "carrier_name": "Frontier",
      "flight_number": "3216",
      "aircraft": "Airbus A321neo",
      "legroom": "28 in",
      "origin_id": "LAX",
      "origin_name": "Los Angeles International Airport",
      "destination_id": "ATL",
      "destination_name": "Hartsfield-Jackson Atlanta International Airport",
      "duration_minutes": 253,
      "departure_date": "2026-09-15",
      "departure_time": "23:50",
      "arrival_date": "2026-09-16",
      "arrival_time": "07:03"
    }
  ],
  "leg_count": 2,
  "layovers": [
    {
      "airport_id": "ATL",
      "airport_name": "Hartsfield-Jackson Atlanta International Airport",
      "city": "Atlanta",
      "duration_minutes": 144,
      "position": "1 of 1"
    }
  ],
  "layover_count": 1,
  "min_layover_minutes": 144,
  "max_layover_minutes": 144,
  "carry_on_bags_included": 0,
  "checked_bags_included": 0,
  "carbon_kg": 284,
  "carbon_vs_typical_percent": -17,
  "arrives_next_day": true,
  "matched_layover_filter": true,
  "raw_flight_data": { "...": "unchanged base object, now also carrying legs[] and layovers[]" }
}

Any field can be missing/null when Google doesn't provide it for a given itinerary (never a fabricated value) — min_layover_minutes/max_layover_minutes are null on nonstop flights, and bag counts are null outside English (hl=en) runs.

Use cases

• Corporate travel approval — screen out itineraries with a connection too tight to make or too long to justify, before a traveler books.
• Fare-and-fit comparison — compare not just price but legroom and aircraft type across itineraries on the same route.
• Sustainability reporting — pull real per-itinerary carbon figures for expense or ESG tracking instead of a route average.
• Baggage-inclusive fare shopping — filter or flag fares that don't include a checked bag before the traveler finds out at the gate.

FAQ

Does this replace the base Google Flights Scraper? It's a superset — every input and output field the base actor has still works exactly the same; this variant only adds new leg/layover/carbon/bag fields on top.

Why is a field null? Google didn't provide it for that itinerary, or (for bag counts) the search wasn't run in English. This actor never substitutes a fabricated value for missing data.

Does the connection-time filter reduce the number of Google requests? No — Google has no server-side parameter for connection minutes, so this actor fetches the full result set and filters afterward. If a tight filter returns few rows, raise maximum before tightening the filter.

Does changing the language (hl) affect anything besides bag counts? No — every other new field is read from the page's structured data, which doesn't change with locale.