Parallel Date Scans
A month of fares in one burst
Each date is one request, and the rate limits are sized for exactly that: fire a whole month in parallel and merge the results.
- 150 / 250 / 500 requests/min on Pro / Ultra / Mega
- A 30-date month scan fits inside a single burst on every paid plan
- The heat grid on the right is real: 30 live requests, LIS→JFK, all of November
Free tier on RapidAPI. No card to try.
01
$448
02
$398
03
$392
04
$386
05
$386
06
$430
07
$404
08
$435
09
$410
10
$398
11
$398
12
$411
13
$398
14
$411
15
$420
16
$411
17
$404
18
$375
19
$398
20
$381
21
$398
22
$435
23
$398
24
$398
25
$381
26
$386
27
$435
28
$448
29
$447
30
$411
Cheapest day: $375 on 2026-11-18. Every cell is one billed request; the whole month cost 30.
The worked example
What a flexible-date search really costs
From the listing itself: “3 to 5 nights, TLV to Paris or Prague, anywhere in May.” Requests are the unit, so the math is public.
31 dates in May
× 3 trip lengths (3–5 nights)
× 2 destinations (CDG, PRG)
= 186 requests
Fired in batches sized to your plan's per-minute limit and merged on price_as_number. This is what makes cheapest-month calendars, fare heatmaps, and "surprise me" search practical to build.
| Plan | Rate limit | Quota / mo | 30-date scans / mo | The 186-req example | One scan costs |
|---|---|---|---|---|---|
| PRO | 150 / min | 2,500 | 83 | ~2 min | $0.12 of quota |
| ULTRA | 250 / min | 10,000 | 333 | one burst | $0.07 of quota |
| MEGA | 500 / min | 50,000 | 1666 | one burst | $0.03 of quota |
Scans-per-month and per-scan cost are straight arithmetic on the live listing's quotas and prices. Nothing estimated. Overage stays available on every paid plan if a scan lands past the quota.
In code
The scan that produced the heat grid
Reproduce the November capture above: one request per date, parallel workers, merge the cheapest fares.
# one request per date. your plan's rate limit is built for this
curl -X POST "https://google-flights-live-api.p.rapidapi.com/api/google_flights/oneway/v1" \
-H "Content-Type: application/json" \
-H "x-rapidapi-host: google-flights-live-api.p.rapidapi.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-d '{
"from_airport": "LIS",
"to_airport": "JFK",
"departure_date": "2026-11-01",
"currency": "usd"
}'Every response in the scan still carries the full result shape, including the price band and verdict per fare, and an X-Search-Status header per date, so a day that failed to scan is never mistaken for a day with no flights.
Pricing
Pick a plan by scans, not abstractions
| Plan | Price / mo | Requests | $ / 1k req | Overage | Rate limit | |
|---|---|---|---|---|---|---|
| BASIC | Free | 10 / mo | — | hard cap | — | Get this plan → |
| PRO | $10 | 2,500 / mo | $4.00 | $0.003 / req | 150 / min | Get this plan → |
| ULTRArecommended | $25 | 10,000 / mo | $2.50 | $0.003 / req | 250 / min | Get this plan → |
| MEGA | $50 | 50,000 / mo | $1.00 | $0.001 / req | 500 / min | Get this plan → |
Every plan includes every endpoint. You only choose volume and rate limit. Read from the live listing on 2026-08-26; the listing is authoritative.
Questions, answered plainly
- How do I scan a whole month of flight prices?
- One request per departure date, fired in parallel, then merge on price_as_number. The November scan on this page is exactly that: 30 requests, LIS→JFK, one per date, run in parallel batches. The heat grid is the merged result.
- How many requests does a flexible-date search use?
- One per date-and-duration combination. The listing's own worked example, "3 to 5 nights, TLV to Paris or Prague, anywhere in May", is 31 dates × 3 durations × 2 destinations = 186 requests. Fire them in batches sized to your plan's per-minute limit and merge the results.
- Will parallel requests get me blocked by Google?
- The API absorbs that concern rather than passing it to you: requests route through a residential proxy by default (use_ext_proxy, switchable per request), unreadable pages are retried automatically, and any search that still could not complete says so in its X-Search-Status header instead of returning a silent empty array.
- How many full-month scans does each plan cover?
- Straight division of quota by 30 requests per scan: Pro's 2,500 requests/month is 83 full-month scans, Ultra's 10,000 is 333, and Mega's 50,000 is 1666, before overage, which stays available on every paid plan.
- Is there a bulk calendar endpoint that returns a month in one call?
- No, and that is a deliberate honesty about how the data is gathered: every date is a live scan of its own Google Flights page. Each date is one request; the rate limits are sized so the whole month still finishes in about a minute. The free cheapest-month tool on this site runs the same pattern.
- What concurrency should my client use?
- Keep in-flight requests under your plan's per-minute figure: 150 on Pro, 250 on Ultra, 500 on Mega. A 30-date month fits inside a single burst on every paid plan; the 186-request example needs ~2 min on Pro and one burst on Ultra.
- What does a month scan cost?
- Derived from the plan prices: 30 requests is $0.12 of Pro's quota, $0.07 of Ultra's, and $0.03 of Mega's. A daily cheapest-month product on one route runs about 900 requests a month. It fits inside even Pro's quota.
Scan the month, find the day
Rate limits sized for parallel date scans, with a price verdict on every fare that comes back.
Free tier: 10 requests/month. No card to try.