Skip to content

Flight & hotel pricing · REST & MCP

Live fares, and the context to judge them.

Two REST APIs that return what a traveller sees right now on Google Flights and Booking.com — plus the fields that tell you whether a price is any good: Google’s own historical price band, its low / typical / high verdict, and a deep link straight to the itinerary.

Free tier: 10 requests / month, no card. Paid plans from $10 / month.

request
curl -X POST https://api.flightpowers.com/v1/flights/oneway \
  -H "x-api-key: $RAPIDAPI_KEY" \
  -H "content-type: application/json" \
  -d '{
    "from_airport": "JFK",
    "to_airport": "LHR",
    "departure_date": "2026-09-22",
    "limit": 3
  }'
200 — response
[
  {
    "price_insights_low": 65,
    "price_insights_high": 135,
    "price_range_in_relation_to_other_periods": "low",
    "from_airport": "New York (JFK)",
    "to_airport": "London (LHR)",
    "departure_date": "2026-09-22",
    "price": "$56",
    "price_as_number": 56,
    "duration": "6 hr 55 min",
    "duration_seconds": 24900,
    "airline": "Norse Atlantic UK",
    "stops": 0,
    "stops_info": [],
    "departure_description": "8:35 PM on Tue, Sep 22",
    "arrival_description": "8:30 AM on Wed, Sep 23",
    "buy_link": "https://www.google.com/travel/flights?tfs=...&curr=usd"
  }
]

What the response carries

Three fields that decide whether you have to build the hard part yourself.

Anyone can hand you a price. These are the parts that usually cost you a second data source, a pricing model, or a support ticket.

price_insights_low / _high

Google’s own price band

The low and high ends of the historical fare range Google Flights displays for that route and date, as integers, plus price_range_in_relation_to_other_periods — Google’s verdict on today’s fare, "low", "typical" or "high". You get “is this a good price?” without modelling it yourself.

POST /v1/flights/roundtrip

A real paired-leg round trip

One request, one billed call, one sellable itinerary: the chosen outbound drives a filtered return-leg search, and you get a combined price and a single buy_link. Each leg takes its own stop limit, airline filter and time window.

proxy_country

Hotel prices from a chosen country

Every hotels endpoint takes an optional country code and routes that request through a residential proxy exiting there. The same room, priced from five markets, is five calls — which is what rate-parity and geo-pricing monitoring actually require.

Search outcome headers

An empty array is not an answer.

A bare 200 [] is ambiguous: it can mean Google returned no itineraries, or it can mean the search did not complete. Those are opposite facts and a fare-alert app that confuses them sends the wrong alert.

Flight searches served from the RapidAPI host carry the outcome in response headers. x-search-status is one of ok, partial, degraded or empty empty means Google genuinely had nothing, degraded means the search failed and the response says nothing about availability. x-search-reason names the cause. Send "strict": true and a degraded search returns 503 instead of a misleading empty array.

Scope
Verified on the RapidAPI host on 2026-08-25 by making a real call and reading the headers. The same call through api.flightpowers.com returns only quota headers today — that front does not yet forward the search headers. Use the RapidAPI host if your application depends on them.

response headers · RapidAPI host
x-search-status: ok
x-search-results: 3
x-search-combinations: 1
x-search-attempts: 2
x-search-retries: 1
x-search-unreadable-pages: 1
x-search-reason: blocked_page

Surface

Six endpoints, one host, one credential.

api.flightpowers.com fronts both APIs. It stores no key of its own — it forwards yours, so calls are billed to your own subscription.

Flights

  • POST /v1/flights/onewayOne-way search
  • POST /v1/flights/roundtripPaired-leg round trip
Flights API reference →

Hotels

  • POST /v1/hotels/searchSearch a destination
  • POST /v1/hotels/by-namePrice one named property
  • POST /v1/hotels/roomsRoom-by-room breakdown
  • POST /v1/hotels/resolveResolve a name to a property
Hotels API reference →

Beyond REST

Already packaged for the tools you use.

MCP server

A bring-your-own-key, ad-free MCP server for flight search, listed on Smithery. View it →

n8n community node

n8n-nodes-flight-hotel-data on npm — one-way and round-trip flight search, hotel search and lookup. View it →

Agent skills

Eight MIT-licensed skills for cheapest dates, fare watch, trip planning, hotel search and rate-parity monitoring. GitHub →

Apify actors

Both APIs are also published as Apify actors if that is where your pipeline already lives. Flights →

Pricing

Subscribe on RapidAPI. Both APIs start free.

Billing, keys and quota are RapidAPI's. There is no separate account here.

Google Flights Live API

PlanPer monthRequestsRate limitBeyond quota
Basic$010 / monthhard stop
Pro$102,500 / month150 / minute$0.003 per extra request
Ultrarecommended$2510,000 / month250 / minute$0.003 per extra request
Mega$5050,000 / month500 / minute$0.001 per extra request

Read from the live RapidAPI listing on 2026-08-25. RapidAPI bills; one call to any endpoint counts as one request. Check the listing for the current figures before you commit.

Booking Live API

PlanPer monthRequestsRate limitBeyond quota
Basic$010 / monthhard stop
Pro$102,000 / month25 / minute$0.006 per extra request
Ultra$206,500 / month25 / minute$0.003 per extra request
Mega$5025,000 / month50 / minute$0.002 per extra request

Read from the live RapidAPI listing on 2026-08-25. RapidAPI bills; one call to any endpoint counts as one request. Check the listing for the current figures before you commit.

Questions

What exactly does price_insights_low and price_insights_high mean?
They are the low and high ends of the historical price band Google Flights itself shows for that route and date, read from the Google Flights page the search loads. They come back as integers in the requested currency, and they are null when Google does not publish a band for that search. Alongside them, price_range_in_relation_to_other_periods carries Google’s own verdict on the current fare: "low", "typical" or "high".
How is your round trip different from calling a one-way endpoint twice?
POST /v1/flights/roundtrip is a single paired-leg search. The outbound leg selected drives a filtered return-leg query, so the outbound and return you get back are an itinerary that can actually be bought together, at a combined price, with one buy_link. Two independent one-way searches give you two fares that may not be sellable as one ticket. It also lets you filter each leg separately — max_departure_stops and max_return_stops, departure_airline_codes and return_airline_codes, and independent time windows on each leg.
What is proxy_country for?
Every hotels endpoint accepts an optional proxy_country. It routes that single request through a residential proxy exiting in that country, so the prices you get back are the prices a resident of that country sees. Send the same hotel and the same dates several times with different values and you have a rate-parity or geo-pricing comparison. Omit it and the request uses a global rotating pool.
Do I need an account with you?
No. Both APIs are sold through RapidAPI and you use your RapidAPI key. api.flightpowers.com is a pass-through front for the same APIs under one host and one credential — it holds no key of its own, and your calls are billed to your own RapidAPI subscription either way.
Which authentication headers does api.flightpowers.com accept?
x-api-key, x-rapidapi-key, x-rapidapi-token, or Authorization with a Bearer, ApiKey or Token prefix. Headers take precedence over the query string, where api_key, apikey, rapidapi_key and key are also accepted.
What happens when a plan’s rate limit is hit?
A 429 from upstream is returned to you as-is and is never retried, so an exhausted plan cannot be double-billed by a retry. Server errors (500, 502, 503, 504) are retried once.