A practical wrapper around an unofficial source
fast-flights exists because Google Flights is useful and its old public-facing API is not available to ordinary developers. The library recreates search requests using the Base64-encoded Protocol Buffer data inside Google Flights URLs, fetches Google's page, and parses flight information from the returned JavaScript data. The result is a Python interface that looks much calmer than the machinery underneath it.
A basic search supplies one or more flight legs, a trip type, seat class, passenger counts, and language. Version 3 adds a broad set of typed filters: maximum stops, airlines, departure and arrival windows, duration, connecting airports, layover limits, emissions, maximum price, bags, separate-ticket visibility, and basic-economy exclusion. That is enough to build a useful personal fare watcher, travel assistant, or research script without driving a browser manually.
The important word is unofficial. This library does not receive stable records from a documented Google service. It encodes and interprets details that Google can change without notice. The technique is inventive, and the API is convenient, but the operational risk belongs to the user.
The first successful query is easy
The core setup deserves credit. The package requires Python 3.10 or newer, installs with pip, and currently declares only primp, Protocol Buffers, and selectolax as core dependencies. A short example creates a query and passes it to get_flights. Developers who already understand Python data classes and airport codes should be productive quickly. The MIT license is friendly to experimentation and commercial evaluation.
Search construction is the strongest part of the design. Per-leg filters and whole-search filters are clearly separated, units are documented, and hours use each airport's local time. Multi-city and round-trip searches fit the same structure as one-way queries. The README also notes one underlying Google behavior that callers could otherwise misread: the first leg's airline filter currently affects the whole search.
Fetching has three distinct paths. Direct requests are the lightweight default. Bright Data can protect the caller's IP. SearchApi is a sponsored integration offering richer results such as cheaper alternatives, price insights, and booking options. Local Playwright is available as an optional dependency when browser behavior is required. These choices give a prototype room to recover, but they are not interchangeable. A proxy, hosted search provider, and full browser have different costs, latency, data shapes, and failure modes.
Scraper breakage is the product risk
The issue tracker shows why a successful demo is not a reliability test. An open pull request from May 2026 says Google's consent page caused searches to return no flights until a cookie was set. Another describes results moving out of the initial HTML and into a shopping XHR response, requiring browser integrations to capture network traffic. Issue #102 reports the README-style example failing because the expected page element was absent. These reports concern the exact parsing and fetching path under discussion, not unrelated components.
Completeness can be harder to detect than a crash. Issue #97 compares a route where self-transfer combinations visible on Google Flights were missing from library results, with a substantial difference between the cheapest visible and returned options. Issue #101 reports best results appearing in raw data but not in parsed output. A program may therefore return a plausible list while omitting the itinerary a user would have chosen. That makes silent validation more important than ordinary exception handling.
Any serious deployment should record query parameters, result counts, fetch mode, and parse diagnostics. It should alert on empty or sharply changed outputs, periodically compare representative searches with the website, and preserve enough sanitized response data to investigate a parser change. A second supplier is prudent when fares affect customers or money. The README's own roadmap characterizes direct use of Google's internal shopping endpoint as dangerous and potentially ban-worthy, which is refreshingly candid.
Activity has resumed, but ownership is thin
The repository was pushed on August 2, 2026. Release 3.0.1 arrived on June 15, and the development branch identifies itself as 3.0.2. Two substantial pull requests were merged in late July, including expanded filters and a weekend price-monitoring workflow. GitHub lists 34 open issues and PRs together. This is current activity, not an abandoned package.
There is still a clear people risk. In issue #92, opened in December 2025 and still open, the author said other work prevented regular attention to issues and pull requests and invited someone to help maintain the project. Later merges show that work can land, but they do not erase the warning that one person cannot chase every Google change. The project's joking, informal contributing notes also set expectations: this is a community project, not a staffed data service.
Documentation is good enough to start and unusually honest about how the scraper was discovered. The main README covers the API and integrations, and a separate documentation site exists. Operational guidance is thinner. There is no promise of result completeness, response stability, or recovery time after Google changes its pages. Users must supply those safeguards.
Use it where failure is cheap
fast-flights is a strong choice for a personal alert bot, an internal experiment, or a trip-planning prototype where someone can notice and repair bad output. Its query builder saves real reverse-engineering work, and the optional integrations offer an escape route when direct fetching fails.
Do not make it the sole truth for booking, reimbursement, or public price claims. A scraper can be technically healthy and still miss the cheapest itinerary. For higher stakes, use the library behind explicit quality checks and a fallback, or choose a paid flight-search provider with support. The code is useful; the data contract is the fragile part.