Skip to content
← All use cases

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_date varies.
  • 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, with limit kept 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.