Search Booking.com hotels by location, dates and occupancy in one unified schema, with cross-OTA price comparison. Use for hotel discovery on Booking.com. Powered by StayingAPI.
Integrations
Booking.com search
Try itSearch live Booking.com stays by location, dates and occupancy, returned in one unified schema alongside every other booking platform. Use when a user wants to find Booking.com listings. Powered by the StayingAPI REST API / MCP server.
What it does
Search live Booking.com stays by location, dates and occupancy, returned in one unified schema alongside every other booking platform. Use when a user wants to find Booking.com listings. Powered by the StayingAPI REST API / MCP server.
The skill document
Booking.com search
Search live Booking.com stays via StayingAPI — one call, the same unified schema you use for Airbnb, Booking.com, Vrbo and Google Hotels.
Setup
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.
When to use this skill
DO use when the user asks:
- "Find Booking.com places in Split, HR for mid-July"
- "Search Booking.com for a 2-bed under a budget"
Do NOT use when:
- A location appears incidentally in conversation
- The user has one known listing already — use the availability or prices skill
Required headers
Every request needs:
- Authorization:
Bearer $STAYINGAPI_KEY - User-Agent: your agent's name (e.g.
ClaudeCode/1.0).
Base URL: https://api.stayingapi.com/v1.
Tools
GET /v1/search
Discover 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.
Filter results to Booking.com by passing
platforms=bookingto the search call.
MCP (no key pasted into the agent)
On an MCP-capable runtime, connect https://mcp.stayingapi.com/mcp (OAuth 2.1 + PKCE) and use: search_stays.
Platform × endpoint support
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.
The cross-OTA advantage
StayingAPI is cross-platform: Booking.com data comes back in the same unified schema as Airbnb, Vrbo and Google Hotels, 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.
Async & partial failures
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 atdata.result(the same schema the sync call returns;dataitself is just{jobId, result, status}).metacarriespartial,platformResults[]andwarnings[]. A completed job may still return an empty result (data.result: []) — the reason is inmeta.warnings[](e.g.no_results), and empty results charge 0.failed→ HTTP is still 200, not an HTTP error. The failure is nested atdata.error(code,type,message,retryable). Detect it withdata.status === "failed", not a top-levelerror.creditsChargedis 0, andmetacarries only{requestId, creditsCharged, platforms}— do not readpartial,platformResultsorwarningson 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).
Known limitations
- Pagination:
limit/cursorare accepted where documented, but availability depends on the endpoint and the upstream source — treatmeta.paginationas authoritative and stop whenhasMoreis false ornextCursoris null. - Externally-sourced ids: a Vrbo id obtained somewhere other than
/v1/searchmay not resolve upstream and can produce a failed job (all_actors_failed). Prefer ids from/v1/search(platformListingId). - Platform gaps: see the support matrix above —
googlehas no listing or reviews endpoint.
Credits
Number-free by design — failed, empty and blocked calls are never billed, and stay_test_ sandbox calls are always free. Current costs: · full contract: .
Trademark
StayingAPI is an independent service and is not affiliated with, endorsed by, or sponsored by Booking.com. Booking.com is a trademark of its respective owner.
Get your free key → https://stayingapi.com/signup · Docs: https://stayingapi.com/docs
Related skills
Search live Vrbo stays by location, dates and occupancy, returned in one unified schema alongside every other booking platform. Use when a user wants to find Vrbo listings. Powered by the StayingAPI REST API / MCP server.
Search live Google Hotels stays by location, dates and occupancy, returned in one unified schema alongside every other booking platform. Use when a user wants to find Google Hotels listings. Powered by the StayingAPI REST API / MCP server.
Check day-by-day Booking.com availability (the booking calendar) for a known listing over a date window. Use when a user asks whether a listing on Booking.com is open on specific dates. Powered by StayingAPI.
Complete Booking.com toolkit — search, availability, listing detail, price, cross-OTA price comparison and reviews, all in one unified schema. Install this when an agent needs broad Booking.com coverage. Powered by StayingAPI.
Read normalized Booking.com reviews for a listing, with native rating scales preserved. Use when a user wants ratings or guest feedback for a listing on Booking.com. Powered by StayingAPI.