Typed flight searches sit on an undocumented Google response
fast-flights turns airport codes, dates, passenger counts, cabin class, and trip shape into a Google Flights query. Version 3 parses JavaScript data returned by the site and maps it into Python objects. The public API is pleasantly small: create a query, call get_flights, then inspect the results. You get type hints without having to decode Google's Base64 and Protobuf-shaped query parameter yourself.
The tradeoff is structural. Google does not offer this project a supported Flights API contract, so a harmless website change can alter the parser's input. Pull request #107, merged in August 2026, added parsing for shopping XHR responses because itinerary data was no longer always present in the initial script.ds:1 HTML. That kind of repair is normal for a scraper, and it should shape where you use one.
Fourteen newer filters cover many practical searches
Release v3.1.0 includes the extended parameters from pull request #110. Per-leg filters cover departure and arrival hours, stops, duration, connecting airports, layover limits, airlines, and lower-emission results. Search-wide options include a maximum price, 2 bag types, separate-transfer hiding, and basic-economy exclusion. The README notes that hours use local airport time and that Google applies the first leg's airline filter to the whole search.
Those details are useful for alerting and itinerary discovery, but result completeness is unsettled. Issue #97 shows a route where self-transfer combinations visible on Google Flights were absent from the scraper's output. Issue #101 reports that best-flight results were not parsed for another query. A fare monitor should store the query URL and raw diagnostic context so an empty or partial result does not silently become 'no flights available.'
What happened when we ran it
Our fresh Debian sandbox installed 37 packages in 21 seconds and used 63 MB on disk. The build completed in 6 seconds. Pytest then passed 8 of 8 tests in 8 seconds, and pip-audit found 0 known vulnerabilities. For a 49-file Python repository with about 5,082 source lines, the local development path was quick and clean.
The checkout had 2 CI workflow files and a tests directory, with no Dockerfile. Our run exercised the repository's available automated checks. It did not prove that a particular live route returns every fare, because the supplied measurement block contains no route search or comparison with the Google Flights UI. That distinction matters more here than it would for a library whose input format is owned by its maintainers.
Direct requests are simple until consent or blocking appears
The basic library call does not require a vendor credential. Google can still respond differently by IP, region, cookies, or request pattern. Open pull request #108 says a Google consent page caused searches to return 'No flights found' and proposes setting a consent cookie. Earlier issue #70 described a consent or language-selection page after bot detection. A successful Python install does not remove those network conditions.
The repository offers 3 escape routes. Bright Data can proxy requests, the sponsored SearchApi integration returns its own richer result type, and local Playwright can use a browser. Each changes the cost and operating model. SearchApi becomes an external paid dependency, Bright Data needs account configuration, and Playwright adds browser deployment. Pick one deliberately and log which route produced each result.
Search results are not booking inventory
fast-flights is most credible as a discovery layer. It can help an internal tool shortlist routes, populate a travel assistant, or watch broad price movement. A customer-facing workflow needs another source for fare rules, availability, taxes, passenger details, and ticketing. The README only attributes booking options and price insights to the SearchApi result, not to every direct result returned by the core library.
The 63 MB installed footprint makes experiments cheap, while false certainty is expensive. Cache timestamps, expose the source to users, and recheck a selected itinerary with a booking-capable provider before presenting it as purchasable. If missing self-transfer routes would change the recommendation, this parser cannot be your only comparison set while issue #97 remains representative of current behavior.
August 2026 work is active despite limited maintainer time
GitHub recorded the last push on August 18, 2026, the same day v3.1.0 was released. The repository had 1,939 stars and 33 combined issues and pull requests when fetched. Recent contributors added filters and corrected tuple handling for dates and times. Those are concrete signs of current work, even though the queue is sizeable for a small project.
Issue #92 adds an unusually direct maintenance warning. In December 2025, the maintainer said they were busy with other work and could not respond whenever Google changed the site, while offering to explain the code to another maintainer. Community patches have landed since then, so the project is not abandoned. Adoption still means accepting that upstream breakage may wait for a volunteer who can reproduce and repair it.