Google Hotels Scraper

Google does not sell hotel rooms. Hotels and booking sites feed their rates into Google for one specific itinerary, which is why a price on that page belongs to a set of dates rather than to the hotel.

The actor searches with the check-in and check-out you supply and returns one row per property: name, nightly price, stay total, currency, star rating, review count, hotel class, type, thumbnail and a link to the Google listing.

You search in plain phrases, the same ones you'd type into Google: "hotels in Lisbon", "family hotels near Disneyland Paris". Add check-in and check-out dates and the prices come back for your stay instead of Google's default one.

No login, no API key.

What you get

{
  "propertyToken": "ChcIhOzxxLOE6-8BGgsvZy8xdG0yYnl0ORAB",
  "searchQuery": "hotels in Lisbon",
  "name": "Independente Principe Real",
  "vendor": null,
  "price": 37,
  "priceText": "US$37",
  "currency": "USD",
  "totalPrice": 49,
  "totalPriceText": "US$49",
  "rating": 4.3,
  "reviewsCount": 1011,
  "hotelClass": 3,
  "hotelType": "hotel",
  "thumbnail": "https://lh3.googleusercontent.com/gps-cs-s/AHRPTWnxuzoBEzeQ...",
  "detailsUrl": "https://www.google.com/travel/hotels/entity/ChcIhOzxxLOE6-8BGgsvZy8xdG0yYnl0ORAB",
  "checkInDate": "2026-09-18",
  "checkOutDate": "2026-09-20",
  "scrapedAt": "2026-08-21T14:37:39.825Z"
}

Prices come as both a number and Google's own string. price is whatever the card labels per night, totalPrice is whatever it labels as the total. Don't expect one to be the other times the number of nights. The row above says $37 nightly and $49 total, and that isn't a parsing bug: Google prints those two figures from different rates, often from different booking sites, on the same card. Take each at face value and use totalPrice when what you care about is the cost of the stay.

checkInDate and checkOutDate are echoed onto every row, so a dataset built from several runs across different dates stays readable without you tracking which run was which.

resolvedLocation is the destination Google actually searched, taken from its own results heading. Ask for "hotels near the Eiffel Tower" and it reads Paris. It's worth glancing at, because it's the difference between the place you meant and a place Google settled on.

propertyToken is Google's stable id for the property. It's the field to key on if you're tracking the same hotel's price over time, since names get reformatted.

Input

{
  "searchQueries": ["hotels in Lisbon", "family hotels near Disneyland Paris"],
  "checkIn": "2026-09-18",
  "checkOut": "2026-09-20",
  "adults": 2,
  "currency": "EUR",
  "country": "fr",
  "language": "en",
  "maxItemsPerQuery": 50
}

• searchQueries — natural destination searches. Up to 10 per run.
• checkIn / checkOut — YYYY-MM-DD. Both optional, but supply them: without dates Google shows its own default stay, and the prices you get back are for that, not yours.
• adults — 1 to 12, default 2.
• country — two-letter Google edition code (us, gb, fr, ca). Default ca. This changes results and pricing more than people expect.
• currency — three-letter hint like USD, EUR. Google may ignore it and use the currency for the country edition, which is why every row carries currency explicitly.
• language — interface language, default en.
• maxItemsPerQuery — default 50, ceiling 100.

Limits

• A destination Google can't place gets you nothing, on purpose. Google never answers "no such place". If it can't work out where you mean, it quietly serves hotels near whichever address the request came from and the page looks completely normal — real hotels, real prices, real ratings, in a city you never asked about. This actor checks the destination Google says it searched against the one you asked for, and when they don't match it returns a note explaining that instead of the rows. Nothing is delivered and nothing is charged. If a search comes back that way, it's usually a spelling slip or a place name that needs narrowing: "Springfield Illinois" rather than "Springfield".
• 10 searches per run, 100 hotels per search. A broad city search won't return every hotel in the city. You get Google's own results list, deepened as far as the cap.
• Prices are live and they move. A price scraped this morning may not exist this afternoon. Anything price-tracking needs repeat runs, keyed on propertyToken.
• adults is sometimes ignored. Some public result layouts don't honour it. Google decides that, not the actor.
• vendor is often null. Google doesn't always name which booking site the rate came from on the results page.
• Dropping the dates makes prices non-comparable across runs. Always set them for anything serious.
• Rating and review count come from Google, not the hotel or a booking site, so they won't match a Booking.com figure.

Proxy

The run goes direct first. If Google blocks it, rate-limits it, or hands back a page with no properties, fallbackToProxy retries through Apify Proxy. It's on by default. Turn it off to keep every request on the platform's own address.

Residential or SERP proxies may be needed for high-volume or geo-sensitive work, and those are metered. They cost extra on top of the per-hotel price below. Worth knowing before you scale a run up.

Billing

$3.50 per 1,000 hotel listings, and there is no run-start fee.

Charged per hotel row delivered. A search that comes back empty costs nothing, and neither does one where Google couldn't place your destination. Your ceiling per run is 10 searches × 100 hotels × $0.0035, so $3.50 at the absolute maximum, before any proxy bandwidth you opt into.