Use case
Fare analysis with a baseline included
Track routes over time and judge every observation against Google's own price band, from day one.
Fare and rate analysis has a cold-start problem: a price observation means little until you have enough history to say what normal looks like, and building that history takes months of collection before the first useful chart. Wide sweeps make it worse: hundreds of route-dates per day strain both rate limits and budgets. And any gap or failed scrape in the series silently skews the trend it was supposed to reveal.
How FlightPowers helps
Analysis-grade fields, sweep-grade limits
Google's band on every observation
price_insights_low/high is a per-route, per-window baseline computed by Google, attached to each result. Your first day of data already knows whether each fare was low, typical, or high for its route.
Rate limits that fit sweeps
150 / 250 / 500 requests/minute across the paid tiers. A daily sweep of hundreds of route-dates runs as a short burst, and the Mega tier's pricing is built for exactly this volume.
X-Search-Status protects the series
Every response states whether it completed. Store the status with the observation and your pipeline can exclude degraded reads instead of letting failed scans masquerade as price drops.
Key workflows
From sweep to signal
- Define the panel. The route-date pairs you care about: a competitor's network, a hub's top markets, a season's inventory.
- Sweep on a schedule. One request per route-date, fired in parallel batches inside your plan's per-minute limit.
- Store number, band, and status.
price_as_number, the two band fields, the verdict, andX-Search-Status: five columns that make the series analysable and auditable. - Chart fare vs. band. Movement inside the band is noise; movement relative to the band is the signal a bare price series can't show.
- Add the hotel dimension. Sweep destinations on the Booking.com API, and vary
proxy_countryto add per-market rates to the model.
Questions, answered plainly
- How is this better than collecting prices and computing my own baseline?
- You still collect the time series. But every observation already carries price_insights_low and price_insights_high, Google’s historical band for that route and date window. Your dataset is normalisable from the first day of collection instead of after months of warm-up, and “fare vs. its own route’s usual range” is a column, not a model.
- How wide a sweep can one plan sustain?
- One route-date is one request, so a daily sweep of 100 route-dates is ~3,000 requests a month, inside the Ultra plan (10,000/month at 250 req/min). Mega (50,000/month at 500 req/min, the lowest per-1k price) fits daily sweeps in the low thousands of route-dates. The per-minute limits mean a sweep is a burst, not an hours-long crawl.
- Can I do the same for hotels?
- Yes: the Booking.com API sweeps a destination across dates for rate movement, and proxy_country adds a per-market dimension flight data doesn’t have: the same property tracked as seen from different countries. The rate-parity and comp-set use cases cover those patterns.
Start the series with the baseline built in
Live fares, Google’s band on every row, and volume tiers priced for daily sweeps.
Free tier: 10 requests/month. No card to try.