Is it possible to retrieve OTA/reseller prices (Expedia, Gotogate, eDreams, etc.) in addition to airline-direct fares?

[housine35]

Question

The current SearchFlights.get_booking_options() method calls Google's GetBookingResults endpoint and returns only airline-direct fare cards (e.g. for an Air France flight, just the Air France entries with Basic/Main/Plus tiers). This is consistent with the existing fixture test test_booking_options_live_fixture.py which asserts exactly 3 AA fare cards for JFK→LAX.

However, the same endpoint, called from a real browser session on the Google Flights booking page, returns a response ~5x larger (74 KB vs 14 KB) containing the full list of resellers: Expedia, Gotogate, eDreams, Booking.com, Kiwi.com, Mytrip, Trip.com, BudgetAir, lastminute.com, wego, Flightnetwork, etc.

Is retrieving this complete reseller list something the library could support, or is it out of scope?

What I tested

For CDG↔HND round-trip (Air France nonstop, 2026-06-10 / 2026-06-24, EUR locale):

• Via fli (SearchFlights.get_booking_options()): 1 vendor returned — Air France direct, 1482 EUR. Response body: 14 KB.
• Captured from browser (HAR file, same itinerary, same session): 12 vendors returned by the same GetBookingResults endpoint. Response body: 74 KB.

Vendors returned to the browser:

#	Type	Vendor	Price EUR	Code
1	DIRECT	Air France	1482	AF
2	OTA	Flightnetwork	1489	ETRAVELI_FLIGHTNETWORK
3	OTA	Gotogate	1490	ETRAVELI_GOTOGATE
4	OTA	Mytrip	1490	ETRAVELI_MYTRIP
5	OTA	Booking.com	1492	BOOKING
6	OTA	BudgetAir	1495	TRAVIX
7	OTA	Expedia	1495	EXPEDIA
8	OTA	eDreams	1498	EDREAMS
9	OTA	lastminute.com	1500	LASTMINUTE
10	OTA	wego	1536	WEGO
11	OTA	Kiwi.com	1548	KIWI
12	OTA	Trip.com	1593	CTRIP

Notably, the existing parse_booking_chunk() parser already handles all 12 rows correctly when fed the captured 74 KB response — BookingOption.is_airline_direct resolves correctly, vendor_code / vendor_name / price / booking_url / google_click_url are all populated. So the parser is not the limitation.

Differences between the two requests

I compared the live-captured browser request and the request fli sends:

1. Inner booking token, field 2: browser sends "AF279" (just airline+flight); build_booking_token() sends "AF279#1" (with #leg_index suffix). Tested both — no effect on the response.
2. Inner booking token, field 14: browser sends a different integer than field 1 (e.g. 148137 vs 172631); the current code duplicates field 1 in field 14. Doesn't appear load-bearing either.
3. Main filter struct uses Freebase MIDs: [[['/m/05qtj', 5]]] (Paris city) and [[['/m/07dfk', 5]]] (Tokyo city) instead of IATA airport codes [[['CDG', 0]]]. Tested with MIDs — no effect.
4. outer[3]: browser sends 1, current code sends 0. Tested with 1 — no effect.
5. URL query parameters sent by browser but not by fli: f.sid, bl, _reqid, soc-app=162, soc-platform=1, soc-device=1. Tested — no effect.
6. Special HTTP headers sent by browser: X-Same-Domain: 1, x-goog-ext-259736195-jspb, Referer: <booking page URL>. Tested — no effect.
7. Cookies: browser sends AEC, SOCS, NID, __Secure-STRP, DV, OTZ. Tested with full session warmup (homepage → /travel/flights → search → booking-page GET → API POST). No effect on the API response size.
8. X-Goog-BatchExecute-Bgr header: a long base64-ish token (likely a BotGuard / browser-environment-attestation challenge response generated by Google's obfuscated JS). The current code does not send this. This appears to be the gatekeeper — when absent, Google returns the stripped 14 KB / airline-direct-only response; when present (real browser), it returns the full 74 KB with all OTAs.

I also tried replaying the exact captured request (same f.sid, same Bgr token, same cookies, same body) shortly after capture — Google returned the stripped 14 KB response. The Bgr token appears to be single-use and/or bound to the originating session/IP, so replay isn't a path.

Question for maintainers

Two angles I'd appreciate input on:

1. Is this a known limitation? The current behavior (1 vendor for AF, ~3 fare cards for AA in the fixture) is consistent — GetBookingResults without BotGuard validation returns only airline-direct. The README and BookingOption model docstring describe the result as "a list of vendors (airline direct and OTAs)", which suggests the OTA case was intended to work at some point. Was it ever returning OTAs in practice, or has Google tightened the gate since the library was written?

2. Is there an HTTP-only path you've explored? I tested URL params, headers, cookies, Referer, session warmup, exact replay — nothing without BotGuard returns OTAs. Two known paths to bypass it (Playwright-driven Chromium with network interception; running the BotGuard JS bundle in a JS runtime with a mocked browser env) both have significant downsides. Would either be welcome as an opt-in extension, or do you see another angle I'm missing?

Happy to share the redacted HAR file and the experimental scripts if useful.

Thanks for the library — get_booking_options() returning even the airline-direct fares programmatically is already extremely valuable.

[punitarani]

Hi @housine35, this could be worth looking into. Can you share a few HAR files and relevant data to look into. Thanks!

[housine35]

[housine35]

www.google.com_Archive [26-05-20 10-00-37].txt

I modified the extension to txt ( remplace har if need)

[nicolas-stein]

Not directly related but some flight search results are also missing when the X-Goog-BatchExecute-Bgr header is not present.

Currently SearchFlights.search() seem to only return results from the Google Flights tab "Best" but is missing results from the tab "Cheapest". My quick investigation also points to the X-Goog-BatchExecute-Bgr header, the Google Flights API returns more/all flights when the header is included in the request.

Findings on this issue for booking options could also benefit the flight search.

[romualdoag]

Workaround: Patchright + response interception

tl;dr — We confirmed X-Goog-BatchExecute-Bgr is the gatekeeper for both GetShoppingResults (Cheapest tab / full results) and GetBookingResults (OTA vendors). We worked around it using Patchright (a drop-in Chromium fork that bypasses reCAPTCHA Enterprise bot detection) with Playwright's network interception API to capture the full browser-generated response body.

Workaround implementation

from patchright.async_api import async_playwright

async def fetch_with_bgr(origin, dest, date):
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context(locale="pt-BR")
        page = await context.new_page()

        captured_body = None

        async def on_response(response):
            nonlocal captured_body
            if "GetShoppingResults" in response.url and response.status == 200:
                body = await response.body()
                if captured_body is None or len(body) > len(captured_body):
                    captured_body = body

        page.on("response", on_response)

        url = f"https://www.google.com/travel/flights?q=One+way+flights+from+{origin}+to+{dest}+on+{date}&curr=BRL&hl=pt-BR&gl=BR"
        await page.goto(url, wait_until="networkidle", timeout=45000)
        await page.evaluate("window.scrollBy(0, 500)")
        await asyncio.sleep(18)  # see streaming note below

        await browser.close()
    return captured_body

Since Patchright runs a real Chromium instance, the BotGuard JS executes natively and the full X-Goog-BatchExecute-Bgr token is attached to every request automatically — no reverse-engineering needed.

Additional discovery: GetShoppingResults streams multiple WRB chunks

While debugging price discrepancies, we captured a full HAR session and found something not documented in this issue:

GetShoppingResults responses are streamed as multiple length-prefixed WRB frames in a single HTTP response, completing over 11–17 seconds (measured via HAR timings.receive). A VIX→MCO one-way search returned 17 separate wrb.fr chunks, 190 total flight rows, with the cheapest fares (e.g. R$1,607) only appearing in chunks 5–16.

The current fli parser calls json.JSONDecoder().raw_decode() once and returns after the first wrb.fr frame, silently dropping all subsequent chunks. This means SearchFlights.search() misses cheapest results even when X-Goog-BatchExecute-Bgr is present — the token unlocks all chunks but the parser discards them.

Our fix iterates all frames:

dec = json.JSONDecoder()
pos = 0
all_flights = []
while pos < len(text):
    # skip length-header lines (start with digit)
    # raw_decode each [...] frame
    # collect inner[2] (Best) + inner[3] (Cheapest) from every wrb.fr chunk

Proposed plan for the library

1. Fix the WRB parser to iterate all streaming chunks — this is a correctness bug independent of browser vs HTTP path. Even with a valid Bgr token, fli's HTTP path sends one request and the server may stream multiple frames in the response.

2. Add an optional browser=True backend to SearchFlights.search() and get_booking_options() using Playwright/Patchright. This would:

   • Accept a playwright_browser context as an optional argument (caller manages lifecycle)
   • Intercept GetShoppingResults / GetBookingResults responses from a real navigation
   • Parse all streamed WRB chunks
   • Fall back to the current HTTP path when browser=False (default)

3. Fix get_booking_options() for OTAs — same Patchright approach: navigate to /travel/flights/booking?tfs=... and intercept GetBookingResults. The existing parse_booking_chunk() already handles all 12 OTA rows correctly per the OP's tests; the only gap is getting the full response body.

4. Note on wait time — when using browser interception, you must wait for the full stream (we use asyncio.sleep(18) after networkidle). networkidle alone is insufficient because Playwright considers long-running streaming connections idle after 500ms of no new requests.

Happy to contribute a PR for any of the above if the direction looks right.