Skip to content

Flight Price Insights API

Fares with a verdict attached to the number

Send a route and a date; get live fares with Google's own price band and a low | typical | high call on each.

  • price_insights_low / high: Google's historical band for the route & dates
  • price_range_in_relation_to_other_periods: the verdict, straight from Google
  • On every plan, on every search, including round-trips and the free tier

Free tier on RapidAPI. No card to try.

POST /api/google_flights/oneway/v1
captured run · 2026-08-26
{
  "from_airport": "JFK",
  "to_airport": "CUN",
  "departure_date": "2027-01-01",
  "limit": 5,
  "currency": "usd"
}
Replays the captured request: free, no account, nobody's quota.

Short answer

What a price insights response looks like

Every fare FlightPowers returns carries Google's own price band. One POST to /v1/flights/oneway on api.flightpowers.com (or to google-flights-live-api.p.rapidapi.com with a RapidAPI key) returns price_insights_low, price_insights_high and price_range_in_relation_to_other_periods on every result, so you get a low typical high call on the fare without keeping any price history of your own. The body is a plain JSON array of itineraries with no envelope to unwrap, and how the search went is in the X-Search-Status response header.
the call that produced it · no sort_type, which would null the band
curl -X POST "https://api.flightpowers.com/v1/flights/oneway" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $FLIGHTPOWERS_API_KEY" \
  -d '{"from_airport":"LAX","to_airport":"SFO","departure_date":"2026-10-21"}'
200 OK · X-Search-Status: ok · LAX → SFO, 2026-10-21 · captured 2026-09-05 · the cheapest itinerary, every field it returns
[
  {
    "price_range_in_relation_to_other_periods": "low",
    "price_insights_low": 25,
    "price_insights_high": 85,
    "from_airport": "Los Angeles (LAX)",
    "to_airport": "San Francisco (SFO)",
    "departure_date": "2026-10-21",
    "price": "$19",
    "price_as_number": 19,
    "duration": "1 hr 35 min",
    "duration_seconds": 5700,
    "buy_link": "https://www.google.com/travel/flights?tfs=GjwSCjIwMjYtMTAtMjEiIAoDTEFYEgoyMDI2LTEwLTIxGgNTRk8qAkY5MgQ0NTkzagUSA0xBWHIFEgNTRk9CAQFIAZgBAg&curr=usd",
    "airline": "Frontier",
    "stops": 0,
    "stops_info": [],
    "departure_description": "7:03 PM on Wed, Oct 21",
    "arrival_description": "8:38 PM on Wed, Oct 21"
  }
]
FieldTypeMeaningAbove
price_insights_lownumber | nullBottom of Google's usual price range for this route and date.25
price_insights_highnumber | nullTop of that range.85
price_range_in_relation_to_other_periods"low" | "typical" | "high" | nullGoogle's verdict on this fare against that range. Branch on it directly.low
price_as_numbernumberThe fare itself, unformatted, so you can compare it to the band. price is the same value as a display string.19

What the three words mean, in plain terms. low means the fare in front of you sits under the range that route and those dates usually cost, so it is cheap against its own history and not just cheap-looking: the buy signal. typical means it sits inside the range, which is the ordinary case and not a reason to wait. high means it sits above the range, so the same trip has recently been cheaper and probably will be again. In the capture above, $19 against a $25 to $85 band reads low.

The verdict is Google's, not ours. Google Flights publishes a usual price range for that route and those dates, and the API passes the range and Google's call on the current fare through untouched. Nothing is modelled on our side, and the fields are null when Google shows no band.

Scoping the claim honestly: SerpApi and HasData document a band of their own, so a band is not unique to us (their docs, read 2026-09-06). What is ours is the round-trip. The same three fields ride on the paired itinerary from /v1/flights/roundtrip, so one request gives you a verdict on the whole trip instead of two one-ways you have to add up.

The three fields

What the response tells you

Captured from a real search (JFK→Cancún, January 1) on the date stamped above.

price_insights_lownumber | null

The bottom of Google's historical price range for this route and these dates. In the capture: $140.

price_insights_highnumber | null

The top of the band. In the capture: $180. A fare under the low end is objectively cheap for the route; over the high end, objectively expensive.

price_range_in_relation_to_other_periods"low" | "typical" | "high" | null

Google's own comparison of the current fare against that band: the field your alerting, ranking, and "book now" logic can branch on directly. In the capture: typical

The captured fare ($177) on Google's band for JFK→CUN

$140 low$180 high

This is the whole feature in one picture: the band says what the route usually costs, the dot says what it costs right now. Rendering this, or just reading the verdict, is one field access.

Patterns

Three things this field replaces

Each of these normally requires months of your own fare history. The band ships it in the response.

A price alert without a database

python · poll & alert
fares = search("JFK", "LHR", "2026-12-10")
best = min(fares, key=lambda f: f["price_as_number"])

if best["price_range_in_relation_to_other_periods"] == "low":
    alert(f"JFK→LHR is LOW: {best['price']}",
          link=best["buy_link"])

An agent that can say "book it"

the tool response your agent reads
{
  "price": "$177",
  "price_insights_low": 140,
  "price_insights_high": 180,
  "price_range_in_relation_to_other_periods":
      "typical"
}
// "That fare is typical for this route.
//  The usual range is $140 to $180."

Ranking results by value

javascript · sort by value, not price
const rank = { low: 0, typical: 1, high: 2 };
flights.sort((a, b) =>
  rank[a.price_range_in_relation_to_other_periods] -
  rank[b.price_range_in_relation_to_other_periods] ||
  a.price_as_number - b.price_as_number
);

Pricing

Every plan carries this field

PlanPrice / moRequests$ / 1k reqOverageRate limit
BASICFree10 / mohard capGet this plan →
PRO$102,500 / mo$4.00$0.003 / req150 / minGet this plan →
ULTRArecommended$2510,000 / mo$2.50$0.003 / req250 / minGet this plan →
MEGA$5050,000 / mo$1.00$0.001 / req500 / minGet this plan →

Swipe the table sideways for overage and rate limits.

Every plan on this API includes all of its endpoints; flights and hotels are separate subscriptions. Read from the live listing on 2026-09-11; the listing is authoritative.

Questions, answered plainly

Where do the price insights come from?
From Google Flights itself. Google computes a historical price range for a route and date window and, when available, a verdict on how the current fare compares. The API surfaces those exact values as price_insights_low, price_insights_high, and price_range_in_relation_to_other_periods. Nothing is modelled on our side.
Is the verdict on every result?
No. It appears when Google publishes it for that route and date, which is most well-travelled routes. When Google doesn’t provide a band, the fields are null and your code should treat the fare as unjudged rather than bad. The captured example on this page shows real values.
What values can the verdict take?
price_range_in_relation_to_other_periods is one of "low", "typical", or "high", in Google’s own wording. "low" means the current fare sits below the usual range for that route and dates: the buy signal.
How do I build a price alert with this?
Poll the route on a schedule (a cron, an n8n workflow, or an agent) and fire when the verdict flips to "low". You skip building a price-history database entirely, because Google’s band is the history.
Do competing flight APIs return this?
Some do. SerpApi documents a price_insights object, and HasData documents a priceInsights object with lowestPrice, typicalPriceRange and priceLevel plus a priceHistory array we do not return. Both read on 2026-09-06. Where the field is missing is the RapidAPI shelf: none of the four Google Flights listings ranked above ours documents a price-insights band, a low / typical / high field, or a search-status header, all four pulled on 2026-09-06. So check the docs of whatever you are comparing, and if a listing does not name the field, assume the fare arrives without context. Our comparison pages quote competitors’ own documentation, dated. What is ours on that shelf is the round-trip: the same three fields ride on the paired itinerary, so one request returns a verdict on the whole trip instead of on two legs you add up yourself.
Does it cost extra?
No. The fields ride on every one-way and round-trip search on every plan, including the free tier.

Stop guessing whether a fare is good

One subscription, every endpoint, and Google's own price context on every result.

Free tier: 10 requests/month. No card to try.