Booking.com Reviews Scraper

Booking.com only takes a review from someone who booked the room through Booking.com, so every review there is attached to a real stay. That is why a room type and a pair of dates ride along with the text, and why what the guest liked and what they didn't arrive as two separate fields rather than one block.

This collects the published guest reviews for the properties you list, one row each: the guest's score, the review title, what they liked, what they didn't, their name and country, the room they stayed in, the check-in and check-out dates, the number of nights, and the date the review went up. The property's own score and total review count sit on every row too.

It doesn't stop at the handful of highlights the property page renders. It walks the same review list the page itself loads, page by page, until it has what you asked for.

What you get

A real row from a real run:

{
  "ok": true,
  "propertyName": "The Savoy",
  "propertyUrl": "https://www.booking.com/hotel/gb/the-savoy.html",
  "reviewId": "fe5f882fedb5d698",
  "rating": 10,
  "reviewTitle": "Love the ambiance and location of the Savoy",
  "positiveText": "Fantastic location, really friendly staff, amazing food",
  "negativeText": "Careful about the breakfast - it's a-la-carte unless you have a breakfast deal.",
  "reviewerName": "David",
  "reviewerCountry": "Thailand",
  "reviewerCountryCode": "th",
  "guestType": "Couple",
  "roomType": "Deluxe King Room",
  "stayDate": "Stayed 2026-08-14",
  "checkinDate": "2026-08-14",
  "checkoutDate": "2026-08-16",
  "nights": 2,
  "publishedAt": "2026-08-21T06:46:40.000Z",
  "reviewLanguage": "en",
  "helpfulVotes": 0,
  "partnerReply": null,
  "photoCount": 0,
  "propertyScore": 9.4,
  "propertyReviewCount": 1447,
  "reviewUrl": "https://www.booking.com/hotel/gb/the-savoy.html",
  "reviewKind": "guest_review",
  "reviewSort": "NEWEST_FIRST",
  "scrapedAt": "2026-08-21T16:22:47.994Z",
  "transport": "direct_browser"
}

Field notes worth knowing:

• rating is that one guest's score out of 10. propertyScore is the property's overall average, repeated on every row so a single row already tells you both.
• positiveText and negativeText are Booking's two separate boxes. Either can be null — plenty of guests fill in only one.
• reviewTitle is null on reviews where the guest didn't write one.
• publishedAt is the date the review was posted, as an ISO timestamp. checkinDate and checkoutDate are when they actually stayed, which is usually earlier.
• partnerReply is the property's public response, on the same row as the review it answers. Null when there isn't one.
• reviewUrl points at the property's page, not at a per-review permalink — Booking doesn't publish one.
• transport records how the row was fetched: direct_browser, or <lane>_browser_fallback when the proxy retry produced it.

Input

{
  "propertyUrls": ["https://www.booking.com/hotel/gb/the-savoy.html"],
  "maxReviewsPerProperty": 100,
  "reviewSort": "NEWEST_FIRST",
  "enableResidentialFallback": false
}

Field	What it does
propertyUrls	Booking.com property URLs — hotels, apartments, anything with a property page. Up to 10 per run. Empty input returns one uncharged sample row.
maxReviewsPerProperty	Reviews per property, 1 to 1000. Default 10. Every returned review is one charged result, so ask for what you need.
reviewSort	MOST_RELEVANT (Booking's own default ranking), NEWEST_FIRST, OLDEST_FIRST, SCORE_DESC, SCORE_ASC. Newest first is what you want for monitoring.
enableResidentialFallback	Retry a page once through a proxy after direct traffic is blocked or rate-limited. Off by default.
proxyConfiguration	Settings for that retry. Your own proxyUrls are used exactly as given. Metered Apify groups (RESIDENTIAL, GOOGLE_SERP) are not offered and are swapped for rotating datacenter addresses.

How it reads a property

Booking.com answers a cold request with a JavaScript bot challenge, so the Actor opens the property in a browser and waits for that challenge to resolve. If it never does, the run reports BLOCKED — uncharged — instead of handing you an empty success and calling it a day.

It makes at most one proxied browser retry, only after a BLOCKED or RATE_LIMITED response, and only when enableResidentialFallback is on or you supplied your own proxy servers. That retry uses rotating Apify datacenter addresses or your own servers. Metered per-gigabyte groups are never used, so proxy transfer can't inflate the cost of a run.

Where a property doesn't open its review list at all, the Actor falls back to the review highlights on the property page and marks those rows reviewKind: "featured_public_review" so you can tell them apart.

Pricing

$1.50 per 1,000 reviews ($0.0015 each), and no run-start fee at all. Same rate on any plan, and you're charged only for reviews actually returned.

Sample rows, diagnostic rows, blocked pages and no-result runs are never charged, so a run that finds nothing costs nothing whatsoever. Because there's no start fee, running one property per scheduled check costs exactly the same as batching ten properties into one run — useful if you want a separate dataset per hotel.

Limits

• 10 properties per run, 1,000 reviews per property.
• Published guest reviews only. It doesn't bypass logins or CAPTCHAs and it doesn't reach private guest data.
• A wrong property slug and a bot wall look identical from the outside — Booking answers the challenge and then never hands over a page either way. A BLOCKED row therefore says both things rather than guessing one. Check the URL opens in your own browser before blaming the block.
• Counts and scores are a snapshot at read time.
• Booking can change its page markup. Nothing here promises it won't.