The Google Hotels API returns property cards for a destination and a date range — name, nightly price and the total for the stay, currency, rating and review count, property type, amenities, dates and a link.
Hotel pricing is not a property of a hotel; it is a property of a hotel on given dates for a given occupancy. That is why check_in_date and check_out_date are required rather than optional here, and why a hotel data source that returns "the price" without dates is answering a question nobody asked. Both the nightly rate and the stay total come back, because they diverge more often than they should.
$0.002 per delivered property, up to 50 propertys per run. Nothing delivered means nothing charged.
You send a destination, check-in and check-out dates, and optionally the number of adults and a currency. The collector queries Google Hotels from an exit in your chosen country and returns property cards as rows.
currency deserves an explicit value on every call. Hotel prices are quoted in whatever currency the visitor appears to want, so a series collected without pinning it drifts with exchange rates and looks like rate movement that never happened — the single most common defect in home-grown hotel price datasets.
total_price next to price_value is the other thing to keep. Taxes, resort fees and per-night versus per-stay quoting mean the nightly rate and the actual cost of the stay frequently tell different stories, and only one of them is what a guest pays.
location, check_in_date and check_out_date are all required — the dates are not optional because a price without dates is meaningless. adults sets occupancy, which changes both availability and rate. currency should always be set explicitly for comparable series. country and lang set the exit and locale; max_results caps delivery.
One row per property. price is the display string, price_value the nightly number and total_price the cost for the whole stay — compare on the total when you care what a guest pays. amenities is the list Google shows, which is how you separate comparable properties from superficially similar ones. property_type distinguishes hotels from apartments and guesthouses. check_in_date and check_out_date are echoed onto every row, so a multi-date collection stays one flat table without you tracking which run produced which row.
$0.002 per delivered property ($2 per 1,000). Nothing delivered means nothing charged, and the $2 monthly free credit covers roughly 1,000 propertys here. Volume tiers take up to 30% off.
$0.002 per delivered property, $2 per 1,000. Rate-shopping 20 destinations across 30 future dates at 30 properties each is 18,000 rows, $36 for a full forward-looking rate picture.
The cost driver in hotel data is never the property count — it is the date grid. Ten destinations across ninety days is nine hundred runs. Decide the date resolution deliberately: weekly sampling usually answers the question that daily sampling answers ten times more expensively.
Google's hotel products are all supply-side: Hotel Center and the Hotel Prices feed exist so that hotels and OTAs can submit their rates into Google, not so that anyone can read what others are charging. There is no public Google API returning hotel search results.
The demand-side alternatives are the GDS and aggregator APIs — Amadeus, Sabre, Travelport, and the OTA affiliate programmes. They are the professional route and they give you something scraping cannot: bookable inventory, contracted rates and the ability to actually complete a reservation. They also require commercial agreements, certification, and in most cases a demonstrated booking volume.
The split is clean. Building a booking product: use a GDS or an OTA API. Rate shopping, competitive benchmarking or revenue-management inputs: you need to see what the market is publicly quoting, and that is a search surface.
Travel is one of the most adversarial verticals on the public web, because scraping directly affects revenue management:
What comparable properties quote for the same dates and occupancy — the direct input to a pricing decision.
Track a defined comp set over a forward date range to see who moves first on price and by how much.
Rate and availability patterns by destination and season, at whatever date resolution you are willing to pay for.
Watch a route or destination for a rate below a threshold, with the total rather than the headline nightly figure.
Up to 50 properties per run for one destination-and-date combination. Coverage scales with the date grid rather than with the property cap, so plan the grid before the budget. Runs parallelise up to your plan's rate limit — 60 requests/minute on pay-as-you-go, up to 1,200 on the top tier. Rates are what Google displays publicly, not contracted or bookable inventory.
Legally: displayed prices are public commercial data and collecting public data is generally lawful in most jurisdictions, but Google's terms restrict automated access and travel operators defend their rate data energetically. Prices are not personal data, which simplifies the privacy question. Using competitor rates to coordinate pricing rather than to compete on it is a competition-law problem entirely separate from scraping. Not legal advice.
Not from Google — Hotel Center and the Hotel Prices feed are supply-side products for submitting your rates, not for reading others'. Here there is a free allowance of $2 a month with no card, about 1,000 delivered properties at $0.002 each.
Because a hotel price only exists for specific dates and occupancy. A source that returns 'the price' of a hotel without dates is answering a question nobody asked — rates move with season, day of week, demand and length of stay.
$0.002 per delivered property — $2 per 1,000 — with no subscription. The real cost driver is the date grid rather than the property count: ten destinations across ninety days is nine hundred runs, so choose your date resolution deliberately.
No. It returns what Google displays publicly, which is the right input for rate shopping and benchmarking but is not contracted inventory. To actually sell a room you need a GDS or OTA API with a commercial agreement behind it.
Taxes, resort fees and per-stay charges. Both numbers are returned precisely because they diverge — compare on total_price when the question is what a guest pays, and on price_value when the question is the headline rate.
Always, for anything you will compare over time. Hotel prices are quoted in whatever currency the visitor appears to want, so an unpinned series drifts with exchange rates and looks like rate movement that never happened.
Yes — run the same destination and date combination on a schedule and diff the results. Every row echoes its check-in and check-out dates, so a multi-date collection stays one flat table without you tracking which run produced which row.
Skip the marketing. QuantumProxies.io publishes a machine-readable site map, Markdown for every page, a free MCP server, and APIs billed from the same balance as your proxies.
Connect in one command: npx -y quantumproxies-mcp