Booking.com data.
Without a click-through for every room.

A REST endpoint and MCP tool that returns public Booking.com data as structured JSON. You send a destination or a property link with a Bearer token; you get back properties priced for your dates with every bookable room option, one property in full with its rooms and amenities, or a property's guest reviews with the score broken into seven categories. No Booking.com account, no HTML to parse.

No. Everything returned is what Booking.com publishes publicly — the same properties, prices and reviews anyone can read without signing in. There is no login, no OAuth, and nothing to keep warm.

Both. Every search result carries a headline price for the cheapest bookable stay and a roomOptions array beside it, each entry with its own price and pre-discount originalPrice, how many people it sleeps, whether breakfast is included, whether it is free to cancel and until when, and whether a crib is available. On a measured Lisbon stay one apartment came back at €642.75 with its matching room option priced identically; a four-star hotel in the same search returned seven distinct rooms. You can compare rooms inside one property as easily as properties against each other.

Yes. Money is {amount, currency} — a number and a three-letter code, never a display string to unpick. A measured Lisbon search for 15–18 October returned 21 properties and every one of them was priced, from €434.00 to €1,216. Nothing comes back as "from £89" for you to regex.

No. Search always prices: with no check-in and check-out it picks a stay window, prices everything for it, and reports that window straight back — both on checkIn and checkOut in the response and in plain words in notes. A measured no-dates search came back with "No check-in/check-out was given, so this search used a default stay this service chose (2026-10-17 to 2026-10-18). Pass checkIn and checkOut to price a specific stay." So a price is never quietly for dates you did not ask about.

The response tells you. Every reviews response carries totalReviewCount — the property's full review count as the source reports it — next to reviewCount, which is how many came back, plus hasMore and a note in plain words: "These are 10 of the 3854 reviews the source reports for this property." You never have to make a second call to find out which one you are holding, and an average over a sample is never mistaken for an average over everything.

What the guest liked and what they disliked, as two separate fields rather than one blob — so you can count complaints without splitting sentences. Alongside them: the score they gave, the language they wrote in, the exact dates they stayed and how many nights, the room type they were in, their public first name and country, the kind of trip it was (a couple, a family with young children, a solo traveller), and the property's reply where there is one. Nothing is machine-translated over what the guest wrote.

Yes — seven of them. Every property's score comes back split into staff, facilities, cleanliness, comfort, value for money, location and wifi, each as a number. One measured Paris hotel scored 9.44 on location and 7.82 on facilities: a single "8.5" would have hidden both. The breakdown arrives with the reviews, so one call gets you the reviews and the shape of the scores behind them.

No, and it says so rather than returning a wrong number. The property route is the catalogue — rooms, sizes, bed configuration, amenities, photos, languages spoken at the desk, check-in and check-out windows. Pass dates to it anyway and you get a note back: "This route does not return a live price for this stay. Use search-hotels with the same destination and dates to get this property's priced room options." Search is what prices, and it prices every room.

One thing, worth knowing before you build on it. On that route the single headline review score comes back empty, while the seven category scores beside it are complete. The property's overall score and review count are on every search result and on the reviews route, so nothing is missing overall — it is just not on that particular call. Read the headline number from a search result or a reviews call; read the category detail from any of the three.

A page is about 25 properties — measured pages returned 21 and 26. The response also tells you how many the source reports for the whole destination, which on a measured Lisbon search was 2,403. Treat that as context, not as a walk you can plan: read hasMore and nextCursor to find out whether there is another page. One Lisbon query returned 26 with more available, and the same query later returned 21 with nothing further. hotelCount is always what actually arrived.

A 404 with a message: {"error":"no property was found for \"zz/no-such-hotel-xyz\""}. Not a 503 and not an empty 200 — a wrong id is a wrong request, so there is nothing to retry and nothing to mistake for a property with no data. Send a field the route does not know and you get a 400 naming it, rather than having it silently ignored.

Measured against production on 17 September 2026, three runs each: a one-page search of Lisbon answered in 3.6 to 3.9 seconds, the same for Paris, one property in full in 3.6 to 3.9 seconds, ten reviews in 4.3 to 4.5 seconds, sixty reviews across three pages in 6.1 seconds, and resolving a link in under a tenth of a second.

One credit per page, reported on every response as pagesFetched. A search page is about 25 properties and costs the same whether it comes back full or half empty. A review walk stops early once your limit is reached, and pagesFetched reports what was actually read rather than what you asked for. Reading a Booking.com link is free and reports pagesFetched: 0.

Yes. All four routes are MCP tools on the same FetchLayer MCP server: booking_search_hotels, booking_hotel_detail, booking_hotel_reviews and booking_resolve_url. Tool calls use the same key and are billed exactly like REST, and the agent sees totalReviewCount alongside the reviews, so it can tell you when a rating is based on a sample instead of presenting it as the property's score.