Documentation
Two APIs, documented endpoint by endpoint
Live Google Flights fares and live Booking.com hotel rates, each with full request and response references, captured example runs, and code you can paste. Start with either hub, or jump straight to an endpoint.
Google Flights API
Flights: live fares with a price verdict
Two endpoints over live Google Flights results. Round-trips come back as paired itineraries, and every result carries Google's price band, a low | typical | high verdict, and a booking link.
POST /oneway
One-way search
A route and a date in, every live fare out: full request and response reference.
POST /roundtrip
Round-trip search
Paired-leg itineraries with combined totals; every one-way filter, per leg.
response fields
Price insights
Google’s price band and its low | typical | high verdict, on every result.
response headers
Search status
The X-Search-* headers: telling a real empty apart from a failed search.
rate limits
Parallel date scans
150 / 250 / 500 req/min by plan: flexible dates as one burst.
Full request tables for both endpoints live on the Flights API hub.
Booking.com Hotels API
Hotels: live rates, priced from any market
Search a destination or name a hotel and get Booking.com's live rates, review scores, room types and booking links. Every endpoint accepts proxy_country, the field behind rate-parity and geo-pricing monitoring.
POST /search
Destination search
Free-text destination and dates in; ranked properties with live prices out.
POST /hotel_by_name
Hotel by name
The name a human would type; availability, price and a booking link back.
proxy_country
Geo-pricing & rate parity
Price the same room from any market through a residential proxy.
POST /resolve + /hotel
Competitive-set tracking
Resolve a name to its Booking.com ID once, then pull room-by-room prices.
The request surface and all 24 search filters live on the Hotels API hub.
Auth
One key scheme for both APIs
Each API is a RapidAPI listing with a $0 tier (10 requests/month, hard cap) to verify your integration. Subscribe, then send your key on every request:
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": "JFK",
"to_airport": "CUN",
"departure_date": "2027-01-01",
"limit": 5,
"currency": "usd"
}'Two headers do all the work: x-rapidapi-key carries your key and x-rapidapi-host names the listing. The hosts are google-flights-live-api.p.rapidapi.com for flights and booking-live-api.p.rapidapi.com for hotels; subscriptions are per API.
Plan quotas and rate limits are on the pricing page.
OpenAPI
The spec, and the own-domain front
Both APIs also run under one roof at api.flightpowers.com, with the same RapidAPI key. That front is where the machine-readable spec lives.
The paths mirror the marketplace endpoints: /v1/flights/oneway, /v1/flights/roundtrip, /v1/hotels/search, /v1/hotels/by-name, /v1/hotels/rooms and /v1/hotels/resolve, plus GET /v1/verify for the cheapest possible “does my key work” check. The key goes in x-rapidapi-key, x-api-key, or Authorization: Bearer, whichever your client makes easiest.
- spec · api.flightpowers.com/openapi.json
- interactive reference · api.flightpowers.com/docs
The direct-API integration page covers the front in detail, error shapes included.