Integrations

Booking.com search

Try it

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.

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

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:

  • locationRequired. 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=booking to 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:

platformsearchavailabilitypriceprice-comparelistingreviews
airbnbyesyesyesyesyesyes
bookingyesyesyesyesyesyes
vrboyesyesyesyesyesyes
googleyesyesyesyesnono

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 min equals median and offers has one entry, sometimes a direct-supplier rate rather than an OTA). Read offers.length before 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 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).

Known limitations

  • Pagination: 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.
  • Externally-sourced ids: a Vrbo id obtained somewhere other than /v1/search may 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 — google has 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 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.

3 installs

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.

2 installs

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.

3 installs

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.

2 installs

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.

2 installs

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.

2 installs