Use case
A month of fares in one burst
Fare calendars, flexible-date search, and price heatmaps, built from parallel per-date scans.
“When is it cheapest to fly?” is the highest-volume question in travel, and answering it takes one search per candidate date: thirty-plus live queries for a single route-month. Run serially, that is minutes of wall-clock time per calendar, which is unusable in an interactive product. And every cell in the grid inherits the scraping problem: a date whose search silently failed looks identical to a date with no flights, and your calendar quietly lies.
How FlightPowers helps
Built for the grid, not the single query
Rate limits sized for scans
150 / 250 / 500 requests/minute on Pro / Ultra / Mega. A 31-date month fires as one parallel batch and the grid fills in seconds of wall-clock, not minutes of loop.
A number, not a string, per cell
Every result carries price_as_number alongside the display price: cells sort, min(), and colour-scale without parsing currency strings.
X-Search-Status per cell
Each date's search reports its own outcome. Render “empty” as a real no-flights cell, retry “degraded” cells, and mark “partial” ones: the calendar stays honest at the cell level.
Key workflows
From route to rendered calendar
- Enumerate the dates. One request body per candidate departure date: same route, same filters, only
departure_datevaries. - Fire in parallel batches. Batch to your plan's per-minute limit and merge as responses land; the listing's own example prices a 186-request flexible search this way.
- Keep the cheapest per cell. min on
price_as_number, withlimitkept small since only the top results matter per date. - Colour by the verdict. Google's low | typical | high verdict per fare gives the heatmap a meaning beyond “cheaper than the cell next to it.”
- Re-scan on a schedule. Refresh the grid daily and you have a cheapest-month product; diff it over time and you have fare-trend data.
Questions, answered plainly
- How many requests does a fare calendar cost?
- One search per date cell. A 31-day month for one route is 31 requests; “3 to 5 nights, two destinations, anywhere in May” is 31 dates × 3 durations × 2 destinations = 186 requests. The listing’s own guidance is to fire them in parallel batches and merge: that is what the per-minute rate limits are sized for.
- Won’t a scan that big take minutes?
- Serially, yes, which is why the plans carry 150 (Pro), 250 (Ultra), and 500 (Mega) requests per minute. A month scan completes as one burst of parallel requests rather than a slow loop. Each individual search is still a live scan, so per-request latency tracks route complexity.
- What should an empty calendar cell mean?
- Exactly what the X-Search-Status header says. “empty” means Google genuinely has no itineraries for that date, a real cell value. “degraded” means that request did not complete, and the honest render is “retry” rather than a blank that looks like no availability.
Build the calendar users actually want
Live per-date fares, a sortable number per cell, and rate limits that let a month finish in one burst.
Free tier: 10 requests/month. No card to try.