For agent builders
Travel data, built for AI agents
Live Google Flights and Booking.com prices as flat JSON, with the fields that turn a number into a decision.
- Live Google Flights fares and Booking.com rates, in whatever your agent already speaks
- Every flight carries Google's price band, a low | typical | high verdict, and a working buy_link
- A date range and a list of destinations in one call, and a round trip priced as one request
- Hotels price per market (price_as_seen_from over MCP, proxy_country over REST): rate-parity checks from a single API
- 3 hosted MCP servers, 8 open-source skills, an n8n node, and plain REST: one key authenticates all of it
Free tier: 10 requests/month. No card to try.
{
"price": "$177",
"price_insights_low": 140,
"price_insights_high": 180,
"price_range_in_relation_to_other_periods":
"typical",
"airline": "American",
"stops": 0,
"buy_link": "https://www.google.com/travel/flights?tfs=..."
}
// "$177 is typical for JFK→CUN on these dates:
// The usual range is $140 to $180."A real captured response, trimmed to the fields an agent branches on. The comment is the sentence those fields let it say.
The loop
How agents use FlightPowers
One key, four steps, and every surface points at the same live data.
1
Get one RapidAPI key
The free tier needs no card and verifies your key works. That single key authenticates REST, both MCP servers, and the skills.
2
Pick the surface your stack speaks
An MCP URL for Claude, Cursor, and ChatGPT; skills for Claude Code and OpenClaw; a community node for n8n; plain REST for everything else.
3
Let the agent call the tools
Flat JSON per result: price, band, price context, booking link for flights; price, availability, review score, link for hotels. Small enough to drop straight into a tool result.
4
Branch on the judgment fields
Verdict flips to “low”: alert. Fare under the band: recommend booking. REST reports degraded: retry, and never tell the user “no flights”.
Recipes
Six things you can build this week
Each card names the exact tool chain. The per-agent pages below turn every one into a copy-paste setup.
A fare-alert cron
search_oneway_flightsprice_range_in_relation_to_other_periodsbuy_linkPoll a route on a schedule and alert when prices drop. Send the buy_link in the alert so the user can book from the notification.
A cheapest-week scanner
search_oneway_flightsdeparture_date_from / departure_date_topriceThe MCP tool takes a date range and expands it server-side: one call, not thirty. The agent gets a flight price per day and answers with the cheapest date and what picking it saves. Over REST, the same scan is a parallel burst; the rate limits are sized for it.
A rate-parity watcher
find_hotel_by_nameprice_as_seen_frompriceIdentical calls except price_as_seen_from (proxy_country over REST), each market asked 3 times, then compare the ranges. In a controlled run on 2026-08-28, Germany and Japan answered with the same number every time and Japan sat under Germany on all three properties, while the US market moved between identical requests.
A trip-planning agent that answers with booking links
search_roundtrip_flightssearch_hotelsbuy_linkRound-trip returns paired itineraries with a combined total; the hotel search returns ranked properties with live rates. Every flight carries a buy_link and every property a booking link, so the plan the agent hands back is actionable, not a description.
A hotel comp-set tracker
find_hotel_by_nameavailableprice_stringRun the by-name lookup across a competitive set on a schedule. Sold-out comes back as the same shape with available: false, so the tracker never branches on error formats: it just logs price and availability per property, per night.
A “should I book it now” advisor
search_oneway_flightsprice_insights_low / price_insights_highThe user brings a quoted price; the agent compares it against Google’s own band for the route and dates. Below the low end: take it. Above the high end: wait. The recommendation cites a source instead of a hunch.
The decision
Why not scrape it yourself?
Five ways to get flight and hotel prices into an agent, compared on the three things that end up mattering.
| Approach | Time to first result | Ongoing burden | Price judgment |
|---|---|---|---|
| Headless-browser DIY (Puppeteer / Playwright) | Days: selectors, proxies, consent walls | Breaks on markup changes, and the fixes are yours | None, and an empty page and a failed scrape return the same empty list |
| Official GDS APIs | Weeks: contracting and certification before the first call | An enterprise integration to maintain | Built for ticketing workflows; consumer price context is not the product |
| Generic scraper marketplaces | Hours: pick a scraper, wire up runs | Per-search economics: cost scales linearly with volume | Raw prices with no reference band to judge them against |
| FlightPowers REST | Minutes: one POST with your key | Managed: automatic retries and error handling | Price context from Google Flights |
| FlightPowers MCP | 30 seconds: paste a URL into your client | Hosted; nothing of yours to run | The same context fields, delivered as a first-class tool result |
The competitor rows describe categories, not any single vendor. Evaluate the specific tool you are considering against them. The FlightPowers rows are checkable on this site: the price_range_in_relation_to_other_periods field on the Price Insights page, the config on the MCP page.
The marketplace question
What happens to your code if a listing disappears
Fair question, and the honest answer is a base URL and a key, not a rewrite. Here is exactly why, and the part of it that genuinely does depend on RapidAPI.
A marketplace listing is a distribution channel. It is not where this API lives. The same six endpoints answer on our own domain, and the same key authenticates on both hosts, so moving between them is one line.
# through the marketplace
POST https://google-flights-live-api.p.rapidapi.com/api/google_flights/oneway/v1
x-rapidapi-key: $KEY
x-rapidapi-host: google-flights-live-api.p.rapidapi.com
# on our own domain
POST https://api.flightpowers.com/v1/flights/oneway
x-api-key: $KEYThe spec is a document you can keep
flightpowers.com/openapi.json is served from our domain at a fixed path. Generate your client from it, commit the file, and your integration does not depend on a listing page rendering.
The MCP servers are on our domain too
flights.flightpowers.com and hotels.flightpowers.com, listed in the official MCP registry as com.flightpowers/google-flights and com.flightpowers/booking. A gateway listing is one more door, never the only one.
The client code is open and readable
The agent skills are MIT-licensed on GitHub. Every call they make is in the repository, so nothing about how this API is used is locked inside a wrapper you cannot read.
What genuinely does depend on RapidAPI
Billing. RapidAPI issues the key, meters the usage, and sends the invoice. If that door closed, the key and the invoice would have to move somewhere else. The endpoints, the spec and the response shapes would not.
The claim we are not making: that we cannot go away. Any vendor can, and a page promising otherwise is worth nothing. The useful question is what you would have to change if we did, and for a well-built integration the answer is the base URL, the auth header name, and the field names you already mapped. That is the same work as switching any HTTP dependency, and it is why the spec is published rather than described.
For AI agents
Your agent already knows how to use this
3 hosted MCP servers, 8 open-source skills, and a plain REST API. All first-party, all maintained, all pointing at the same live data.
MCP: no install, just a URL
{
"mcpServers": {
"flights": {
"url": "https://flights.flightpowers.com/mcp",
"headers": { "x-rapidapi-key": "YOUR_KEY" }
}
}
}Skills: for Claude Code & OpenClaw
npx skills add mtnrabi/travel-agent-skills
# then just ask:
# "find me the cheapest week to fly
# JFK to Lisbon this winter"REST: one POST, flat JSON
curl -X POST "https://google-flights-live-api\
.p.rapidapi.com/api/google_flights/oneway/v1" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"from_airport":"JFK","to_airport":"CUN",
"departure_date":"2027-01-01"}'Questions, answered plainly
- What is the fastest way to connect an agent?
- The MCP URL. Paste https://flights.flightpowers.com/mcp into Claude, Cursor, or ChatGPT, sign in with Google, and the four tools appear. No SDK, no install. It is one URL either way: a script or a client without a sign-in button sends the key on that same address. The /mcp page has the exact block to copy.
- Does one key really cover MCP, the skills, and REST?
- Yes. All three surfaces authenticate with the same RapidAPI key and meter against the same plan. You subscribe once on RapidAPI; the MCP servers forward your key, the skills read it from your environment, and REST takes it as the x-rapidapi-key header.
- How do the rate limits map to agent workloads?
- Flights: 150 requests/minute on Pro, 250 on Ultra, 500 on Mega, sized so a month-long flexible-date scan over REST finishes in one burst. Hotels: 25/minute on Pro and Ultra, 50 on Mega. A daily price-watch across several routes fits comfortably in the $10 Pro tier’s 2,500 requests.
- What does the agent actually get back?
- Flat JSON per result. Flights: price as string and number, airline, duration, stops with layover details, and a working buy_link. Hotels: price, review score and count, room type, availability, and a booking link.
- Is there a way to demo without a key?
- The free ad-supported MCP server runs the flight and hotel tools with no RapidAPI key: sign in with Google and you get 50 searches a day and 250 a month. Every result carries one labelled sponsored card and one call searches at most 15 date × destination combinations instead of 30, so it is for trying, not production. The free tools on this site also run live requests on our own key.
Give your agent a travel budget it can defend
Live flight and hotel data, so your agent has current pricing. One key covers MCP, skills, and REST.
Free tier: 10 requests/month. No card to try.