google-hotels-api is a guide to a paid scraping endpoint

What the repository actually contains

The repository is a single README file. There is no source directory, no package manifest, no test suite and no licence file, and the recorded primary language and licence are both blank.

That is worth stating plainly at the start, because it changes what this project is. It is not an open source library and it is not a tool you install. It is a technical implementation guide for a hosted service, the Google Hotels API endpoint offered by ScrapingBee, and the repository is the documentation for it.

The guide itself is well organised for what it is. It explains what Google Hotels is and why extracting it programmatically is harder than it looks, gives the request lifecycle, lists the endpoint, then walks through the parameters in groups, shows the same request in three languages, prints an example response, explains the shape of a hotel record, and ends with the practical uses and a note on pagination. A developer integrating the endpoint would have everything they need from one page.

The trade is that the examples are illustrative rather than executable against a real key. Every request in the guide carries a placeholder API key, and the values for dates and cities are fixed examples, so the code is a template rather than a working integration you can run today.

Why Google Hotels resists ordinary scraping

Google Hotels, part of Google Travel, aggregates hotel listings, pricing, availability, ratings, reviews and booking providers into a dynamic search interface. The README's point is that the interface looks simple while the data extraction is technically complex, because of dynamic pricing, JavaScript rendering and aggressive anti-bot detection.

The second reason is more interesting, and it is about the shape of the query. Google Hotels is not a static listing page, it is a dynamic travel search engine embedded in Google Travel, and the results vary depending on the check-in date, the check-out date, the number of guests, the room count, the geographic location, the currency and language, and the device type.

That list is effectively the schema of the search. Any scraping attempt that omits one of those parameters is not requesting the page a human would see, and any attempt that hard-codes them returns one narrow slice of the data. It also explains why the date parameters are described as directly influencing pricing and availability results, and why the price monitoring example changes dates to produce different pricing for seasonal monitoring.

The README then lists the failure modes of manual scraping: IP blocking, CAPTCHA challenges, inconsistent pricing refresh, layout updates and dynamic map-based loading. Only the first two are adversarial, and the other three are simply the ordinary fragility of scraping a page that is designed to change.

The request lifecycle the service hides

The architecture is described as a sequence, and it is a useful way to think about what you are buying when you use a hosted endpoint.

The client application calls the Google Hotels API, which goes through a proxy and rendering layer, reaches Google Travel, and comes back through a structured parsing engine to produce a JSON response. In other words, the parts of the pipeline that are painful are between you and the search engine, and the contract you program against is the JSON at the end.

The guide splits the responsibilities the same way. You define the destination or hotel query, the check-in and check-out dates, the guest configuration, the location targeting, and the currency and language. The API handles JavaScript rendering, proxy rotation, CAPTCHA mitigation and result normalization.

CAPTCHA mitigation is the one that needs a caveat rather than a reassurance, and it is the same caveat that applies to any hosted scraping service. Solving a challenge on behalf of a client, against a site that is trying to prevent automated access, is a behaviour the target site may not have agreed to, and the terms of the service you use and the terms of the site being scraped are separate documents. That is a decision for the team using it, not something the endpoint can settle, and it is worth making deliberately rather than by default.

The endpoint and the parameter groups

The base endpoint is a single GET on the ScrapingBee host, and activating the hotel mode is a matter of adding the right search parameter:

GET https://app.scrapingbee.com/api/v1/

https://app.scrapingbee.com/api/v1/?api_key=YOUR_API_KEY&search=google_hotels&q=QUERY

The core parameters are the authentication key, the search=google_hotels value that switches the endpoint into hotel mode, and q, the destination or hotel query. The date and guest parameters are check_in and check_out in YYYY-MM-DD form, adults, children and rooms, and the README states plainly that these directly influence pricing and availability results.

The optional targeting parameters are country_code for geographic targeting, language, currency for display currency, device to simulate desktop or mobile, premium_proxy for higher reliability proxy routing, and render_js to force JavaScript rendering.

The device and currency parameters are worth a second look. Because Google Hotels serves different results to different devices and in different currencies, a dataset that mixes those parameters is not comparable with itself, so any monitoring pipeline has to hold them fixed and treat a change as a different query.

The same request in Python and in Node

The guide shows the request in three languages, and the Python version is the clearest illustration of the flow:

import requests

params = {
    "api_key": "YOUR_API_KEY",
    "search": "google_hotels",
    "q": "hotels in New York",
    "check_in": "2024-09-01",
    "check_out": "2024-09-05",
    "adults": 2,
    "rooms": 1,
    "country_code": "us",
    "language": "en"
}

response = requests.get(
    "https://app.scrapingbee.com/api/v1/",
    params=params
)

data = response.json()

for hotel in data.get("hotels_results", []):
    print(hotel["name"])
    print(hotel["price"])
    print(hotel["rating"])
    print("-" * 40)

Nothing clever is happening: a query string, a JSON response and a loop over the hotels_results array. The complexity the README described lives entirely on the other side of the endpoint.

The Node version uses the vendor's own client package, the scrapingbee module with its ScrapingBeeClient class, and passes a url pointing at the Google Travel hotels page along with the same parameter set. The cURL form is the third, and it is the one to reach for when you are testing from a terminal, since it needs nothing installed.

Three implementations of the same request is itself a small finding. The endpoint is an ordinary HTTP API with a stable parameter set, and the choice of client is a matter of taste.

What one hotel record looks like

The example response is small and complete, and it is the most useful thing in the repository for a developer who has to design a schema around it:

{
  "hotels_results": [
    {
      "name": "Grand Palace Hotel",
      "price": "$220",
      "total_price": "$880",
      "rating": 4.5,
      "reviews": 1243,
      "location": "Central Paris",
      "amenities": ["Free WiFi", "Breakfast included", "Pool"],
      "booking_providers": [
        {
          "provider": "Booking.com",
          "price": "$215"
        },
        {
          "provider": "Expedia",
          "price": "$218"
        }
      ]
    }
  ],
  "search_metadata": {
    "query": "hotels in Paris",
    "check_in": "2024-08-01",
    "check_out": "2024-08-05"
  }
}

Each listing may include the hotel name, the nightly price, the total stay price, the star rating, the review count, the geographic location, amenities, booking providers and availability indicators.

Two things in that shape will shape your code. The prices are strings, not numbers, so a currency symbol is baked into the value and any aggregation has to strip it and convert it. And the booking providers carry their own prices, which is the commercially interesting part, because the difference between the price Google shows and the price the booking provider charges is the number a revenue management team is looking for.

The commercial shape, and what the guide leaves open

The use cases the README lists are a price monitoring system, a travel analytics dashboard, a competitive benchmarking tool, a hospitality intelligence platform and a large-scale hotel data scraping pipeline, and the applications section names the roles behind them: travel aggregators monitoring pricing fluctuations across dates, revenue management teams benchmarking competitor pricing, investment analysts tracking hospitality demand across cities, and dynamic pricing models feeding on the structured output.

The pagination note is short and hedged: use offset parameters, when supported, to iterate through additional listings, and combine pagination with varying date ranges to capture broader datasets. The phrase when supported is doing real work, since a pipeline that depends on deep pagination depends on a behaviour the documentation does not promise.

The last limitation is the one that belongs in any evaluation. Everything here is a paid hosted service, and the repository contributes no code, no licence and no fallback. The cost per request is set by the vendor, the rate limits are not described, and the response shape is the vendor's to change. A team that wants hotel data for a dashboard and can accept that dependency will find this guide and the endpoint useful. A team that needs a data pipeline it controls, or one that must answer for how the data was obtained, needs a different approach and should not start here.

Editorial conclusion

This repository fits a developer who needs hotel prices, ratings and booking providers in JSON quickly and would rather not build a scraping stack with proxies, rendering and CAPTCHA handling, since the parameter list and the response shape are the useful part and they are written down here. It does not fit a team that needs self hosted scraping, since the endpoint is a paid hosted service and the repository ships nothing to run. Before adopting the approach, confirm the service's terms permit your use of Google Travel data, budget for a per request key, and check the pagination behaviour, since the README only says offset parameters are used when supported.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. ScrapingBee/google-hotels-api on GitHub