Install
openclaw skills install @stayingapi/google-hotels-fullComplete Google Hotels toolkit — search, availability, price and cross-OTA price comparison in one unified schema. Note: Google Hotels supports neither listing detail nor reviews. Install this when an agent needs broad Google Hotels coverage. Powered by StayingAPI.
openclaw skills install @stayingapi/google-hotels-fullThe everything skill for Google Hotels: search, availability, price and cross-OTA price comparison — one key, one schema. Install the focused skills instead when you want a minimal tool surface.
[!IMPORTANT] Google Hotels supports no listing-detail and no reviews endpoint —
GET /v1/listing/google/…andGET /v1/reviews?platform=googleboth return400 platform_not_enabled, so neither is documented here. Usebooking,airbnborvrbofor those, and note that/v1/searchstill returnsguestRating/reviewCountfor Google Hotels.
If $STAYINGAPI_KEY is not set, read references/auth-setup.md and follow it to get and store the key. A stay_test_ sandbox key works for evaluation at zero cost.
DO use when the user asks:
Do NOT use when:
Every request needs:
Bearer $STAYINGAPI_KEYClaudeCode/1.0).Base URL: https://api.stayingapi.com/v1.
GET /v1/searchDiscover properties matching a location, dates, occupancy and filters across one or more platforms. Results from every requested platform are normalized to the same Property shape and merged into a single, cursor-paginated list. This is the breadth / funnel endpoint — and the clearest demonstration of "one schema, every platform".
Key parameters:
location — Required. Place name ("Split, HR") or "lat,lng".checkIn — YYYY-MM-DD; required if checkOut given; not in the past.checkOut — YYYY-MM-DD; required if checkIn given; must be after checkIn.adults — ≥ 1.children — ≥ 0.childAges[] — Length must equal children. Coarsened for Vrbo/Airbnb.platforms[] — Drives fan-out + per-platform billing.GET /v1/availabilityGet day-by-day availability for a known listing (or a batch of listings) on one platform over a date window. Each day reports whether it is available, its minimum-night requirement, and whether check-in / check-out / booking is allowed.
Key parameters:
platform — Required. vrbo | booking | airbnb | google. Single platform (not a fan-out endpoint). Use the API value, not the brand name — "booking", not "booking-com"; "google", not "google-hotels".listingId — A single listing id on platform.listingIds[] — A batch of listing ids on platform.url — Full listing URL (alternative to an id).startDate — Required. YYYY-MM-DD; not in the past.endDate — Required. After startDate; window ≤ 365 days.GET /v1/priceQuote one listing for specific dates and occupancy. Pass the platform-native platformListingId returned by /v1/search — numeric on Airbnb and Vrbo, a slug string on Booking.com and Google (e.g. "abramovic2") — or a full listing URL. On a live key the response is always a real numeric price or a typed error — never a wrong property's price. Note this guarantee covers live calls: sandbox (stay_test_) responses are canned fixtures and may echo a different listing, dates or occupancy than you requested, so do not assert identity against a sandbox response.
Key parameters:
platform — Required. vrbo | booking | airbnb | google.listingId — Required. Platform-native id from /v1/search platformListingId — numeric (Airbnb/Vrbo) or a slug string (Booking.com/Google). Or pass a url.checkIn — Required. YYYY-MM-DD; not in the past.checkOut — Required. Must be after checkIn.adults — ≥ 1.children — ≥ 0.GET /v1/price-compareRate-shop one property in a single call, resolved through the Google Hotels backbone. The response carries the offers the backbone exposes for that property plus StayingAPI-computed min and median over those offers as first-class fields, so you can read the cheapest rate without re-deriving it. Coverage varies by property: some resolve to several OTA offers, others to a single aggregated-lowest offer (then offers has one entry, min equals median, and the entry may be a direct-supplier rate rather than an OTA). Read offers.length before presenting a result as a multi-platform comparison — the schema does not guarantee more than one.
Key parameters:
name — Property name to resolve.googleHotelId — Precise Google Hotels id.location — Disambiguating place / "lat,lng".checkIn — Required. YYYY-MM-DD; not in the past.checkOut — Required. Must be after checkIn.adults — ≥ 1.Filter results to Google Hotels by passing
platforms=googleto the search call.
On an MCP-capable runtime, connect https://mcp.stayingapi.com/mcp (OAuth 2.1 + PKCE) and use: search_stays, check_availability, get_price, compare_prices.
Not every endpoint supports every platform. Verified:
| platform | search | availability | price | price-compare | listing | reviews |
|---|---|---|---|---|---|---|
airbnb | yes | yes | yes | yes | yes | yes |
booking | yes | yes | yes | yes | yes | yes |
vrbo | yes | yes | yes | yes | yes | yes |
google | yes | yes | yes | yes | no | no |
GET /v1/listing/google/… and GET /v1/reviews?platform=google return
400 platform_not_enabled ("google is not enabled for this endpoint"). Use booking,
airbnb or vrbo for listing detail and reviews; use google for search, price and
cross-OTA price-compare.
StayingAPI is cross-platform: Google Hotels data comes back in the same unified schema as Airbnb, Booking.com and Vrbo, so one integration covers them all. /v1/price-compare resolves a property through the Google Hotels backbone and returns the offers it exposes plus a StayingAPI-computed min and median over those offers, as first-class fields.
Coverage varies by property and by what the backbone returns: some properties come back with several OTA offers, others with a single aggregated-lowest offer (in which case
minequalsmedianandoffershas one entry, sometimes a direct-supplier rate rather than an OTA). Readoffers.lengthbefore describing a result as a multi-platform comparison.
A live call that has to scrape returns 202 with data.jobId, data.pollUrl and
data.estimatedSeconds (the 202 itself charges 0). Poll GET /v1/jobs/{jobId} (free)
until data.status is TERMINAL — completed or failed.
completed → the payload is at data.result (the same schema the sync call returns;
data itself is just {jobId, result, status}). meta carries partial,
platformResults[] and warnings[]. A completed job may still return an empty
result (data.result: []) — the reason is in meta.warnings[] (e.g. no_results), and
empty results charge 0.failed → HTTP is still 200, not an HTTP error. The failure is nested at
data.error (code, type, message, retryable). Detect it with
data.status === "failed", not a top-level error. creditsCharged is 0, and meta
carries only {requestId, creditsCharged, platforms} — do not read partial,
platformResults or warnings on a failed job.Pace your polling: honour the Retry-After header, back off between attempts, and cap the
number of attempts. A tight loop hits 429 rate_limit_exceeded (120 requests/minute).
limit/cursor are accepted where documented, but availability depends on the endpoint and the upstream source — treat meta.pagination as authoritative and stop when hasMore is false or nextCursor is null./v1/search may not resolve upstream and can produce a failed job (all_actors_failed). Prefer ids from /v1/search (platformListingId).google has no listing or reviews endpoint.Number-free by design — failed, empty and blocked calls are never billed, and stay_test_ sandbox calls are always free. Current costs: https://stayingapi.com/pricing · full contract: https://api.stayingapi.com/openapi.json.
StayingAPI is an independent service and is not affiliated with, endorsed by, or sponsored by Google Hotels. Google Hotels is a trademark of its respective owner.
Get your free key → https://stayingapi.com/signup · Docs: https://stayingapi.com/docs