Booking Reviews Scraper — Hotels & Monitor

Why use this Actor?

Booking.com reviews scraper for hotel intelligence. Discover properties by name or destination, export scores, text, guest/stay/room data, photos and partner replies, filter by traveler/language/date/stay details, run summary-only benchmarks, and monitor only new reviews.

Features

• Booking.com hotel URLs — Booking.com hotel pages to scrape, one URL per line, e.g. https://www.booking.com/hotel/us/ace-new-york.html. Can be combined with hotel searches and discovery URLs. Leave empty only when you use one of those.
• Maximum reviews per hotel — Maximum review rows returned (and billed) per hotel after filters, e.g. 200. Booking.com shows up to several thousand reviews for popular hotels.
• Maximum total reviews — Hard cap on review rows across all hotels in this run, e.g. 1000, for predictable runtime and spend.
• Review order — Order in which Booking.com returns reviews: newest, most relevant, oldest, highest score or lowest score first (e.g. 'Lowest score first' to read complaints first). Uses Booking.com's own sort options. With 'Newest first' or 'Oldest first' and a reviewed date range, the Actor jumps straight to that period, so even a month several years back is reached in a few requests.
• Minimum review score — Only return reviews scored at or above this value on Booking.com's 1-10 scale, e.g. 8 for happy guests.
• Maximum review score — Only return reviews scored at or below this value on Booking.com's 1-10 scale, e.g. 5 to collect complaints.
• Reviewed after — Only reviews written on or after this date: YYYY-MM-DD (e.g. 2026-01-01), ISO 8601, or a relative value counted back from the run start such as '7 days', '2 weeks' or '3 months' (ideal for schedules). With newest or oldest order the Actor jumps straight to the requested period.
• Reviewed before — Only reviews written on or before this date: YYYY-MM-DD (e.g. 2026-06-30), ISO 8601, or a relative value such as '30 days'. With newest or oldest order the Actor jumps straight to the requested period.
• Review text contains — Only reviews whose title, positive or negative text contains this phrase (case-insensitive), e.g. breakfast. Filtered-out reviews are not billed.
• Reviewer countries — Only reviews from guests of these countries, as Booking country codes or names, e.g. us, gb, Italy. Empty means all countries.
• Traveler types — Only these traveler types, e.g. COUPLES, SOLO_TRAVELLERS, FAMILIES, GROUP_OF_FRIENDS or BUSINESS_TRAVELLERS. Empty means all traveler types.
• Review languages — Only reviews written in these languages, as Booking.com language codes, e.g. en, it, de, fr. Empty means all languages.
• Free review insights — One free review_insights row per hotel: average score, score distribution, reply rate, traveler types, languages, top reviewer countries, average nights and the share of reviews with photos.
• Your own IDs on every row — Pass hotels as startUrls with userData (e.g. {"crmId": "H-1"}); it comes back as customData on every row of that hotel.
• Privacy switch — Turn off includeReviewerInfo to collect reviews without guests' names.
• Drop-in input — Inputs written for other Booking.com review scrapers (sortReviewsBy, maxReviewsPerProperty, maxReviews, cutoffDate) work as they are.

Use cases

• Hotel reputation monitoring.
• Guest-experience research.
• Competitive hotel benchmarking.
• Review datasets for bi and nlp.

Related tools

• TripAdvisor Reviews Scraper — Search & Monitor
• Trustpilot Reviews Scraper - Ratings, Replies & Filters
• Google Trends Scraper - Keywords, Regions & Trending

Example input

{
  "maxReviewsPerHotel": 500,
  "maxTotalReviews": 5000,
  "sortBy": "newest",
  "minScore": 1,
  "maxScore": 10,
  "minHelpfulVotes": 0
}

Pricing & cost control

The primary event costs $0.001000 per Booking.com review (about $1.00 per 1,000 successful primary events). Only successful primary events are intentionally billed by this Actor; summary/status rows add context without adding primary-event charges.

Use the bounded input limits and filters to keep both event charges and platform usage predictable.

FAQ

What is this Actor for?
It is designed for hotel reputation monitoring, guest-experience research, competitive hotel benchmarking.

Can I run it on a schedule?
Yes. You can schedule Actor runs on Apify and send the resulting dataset into automations, webhooks, storage, or downstream APIs.

How do I control cost and run size?
Use the input limits and filters shown in the Actor input form. The Actor applies bounded defaults and hard caps so large jobs remain predictable.

Pricing at a glance

	Price per 1,000 Booking.com reviews
This Actor	$1.00
Median of 8 comparable Apify Store Actors (October 2026)	$1.65

That is about 39% below the median per-result price for this task in Apify Store.

Subscriber discounts: on a paid Apify plan you pay even less per result — Bronze −10%, Silver −15%, Gold and higher −20% ($0.80 per 1,000 Booking.com reviews on Gold).

Apify platform usage (compute, storage, data transfer) is included — you pay only the result price plus a small run start fee ($0.0001 per GB of run memory). No surprise compute bill, even on long runs.

Use the run's maximum charge setting to cap spending — the Actor stops cleanly when the limit is reached.

Use it from AI agents (MCP) and code

AI agents — Claude, ChatGPT, Cursor, VS Code, n8n AI agents and any MCP client can run this Actor through the official Apify MCP server: add https://mcp.apify.com?tools=zenomastro/booking-reviews-reliable to your client. Then just ask, for example:

"Collect the newest Booking.com reviews for this hotel URL and tell me what guests praise and criticize most."

The agent fills the input from the field descriptions and receives clean JSON it can reason over.

API — one HTTP call runs the Actor and returns the results directly:

curl -X POST "https://api.apify.com/v2/acts/zenomastro~booking-reviews-reliable/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"hotelUrls": ["https://www.booking.com/hotel/us/ace-new-york.html"], "maxReviewsPerHotel": 1, "maxTotalReviews": 1, "maxPagesPerHotel": 2, "includePhotos": false, "includeHotelSummary": true, "retries": 1}'

The same works from the Apify Python/JavaScript clients, Make, n8n, Zapier, LangChain and LlamaIndex integrations, or on a schedule.

Tip: paste Booking.com hotel URLs for the fastest runs. When Booking.com's bot protection blocks direct access, the Actor automatically retries through the Apify datacenter proxy (included in the price). For hard blocks you can enable the residential proxy fallback add-on ($0.10 per residential attempt, off by default).

Extract public Booking.com hotel reviews into clean structured data for hospitality analytics, reputation monitoring, competitor research, guest-experience analysis, customer-support workflows, travel research, and AI/LLM pipelines.

The Actor starts a real browser only to initialize the public Booking.com review session for each property, then reuses Booking.com's own review data flow for efficient pagination. This avoids brittle DOM-only scraping while still validating the live hotel page at run time.

What you get

Successful review rows can include:

• Booking.com review score and review date
• review title, positive text, and negative text
• reviewer display name, country, country code, and traveler label
• Booking traveler/customer type
• room type, check-in, check-out, and number of nights
• helpful-vote count
• public hotel/property reply when available
• public review photos when available
• hotel ID, hotel country code, hotel score, and canonical source URL
• scan/runtime metadata for reproducibility

Optional free hotel-summary rows include the total public review count and aggregate rating, score, language, and traveler-type information returned by Booking.com.

Input

Provide one or more full Booking.com hotel URLs in hotelUrls, or let the Actor find hotels with hotelSearchQueries (hotel or destination names) and discoveryUrls (Booking.com search pages). The example hotel in the input form is only a prefill: API calls that pass only searches or discovery URLs scrape just those.

If the input cannot be used (for example no hotel at all, an invalid date or an unknown sort order), the run still finishes successfully and returns one free error row that explains what to change. Invalid hotel URLs get their own error row while the valid ones are scraped.

Example:

{
  "hotelUrls": [
    "https://www.booking.com/hotel/us/ace-new-york.html"
  ],
  "maxReviewsPerHotel": 500,
  "maxTotalReviews": 5000,
  "sortBy": "newest",
  "minScore": 1,
  "maxScore": 10,
  "reviewedAfter": "",
  "reviewedBefore": "",
  "containsText": "",
  "reviewerCountries": [],
  "customerTypes": [],
  "languageCodes": [],
  "minHelpfulVotes": 0,
  "partnerReply": "any",
  "includePhotos": true,
  "includeHotelSummary": true,
  "maxPagesPerHotel": 100,
  "autoProxyFallback": true,
  "proxyConfiguration": {
    "useApifyProxy": false
  }
}

Sort orders

sortBy uses Booking.com's own sort options:

Value	Order
newest (default)	Newest reviews first
most_relevant	Booking.com's most relevant order
oldest	Oldest reviews first
score_desc	Highest scores first
score_asc	Lowest scores first (complaints first)

The hotel_summary row records sortRequested and the Booking.com sorter actually used (sortApplied). If Booking.com ever stops offering an order for a hotel, the Actor uses Booking.com's default order and adds a free status row saying so. With newest or oldest and a reviewed date range, the Actor jumps straight to that period and stops as soon as it leaves it (see Reviews from a specific period).

Filters

Filters are applied before paid review rows are emitted. You can combine score range, date range, text substring, reviewer country, traveler/customer type, language, minimum helpful votes, and hotel-reply presence.

Filtered-out source reviews are not billed.

For country filtering, use a Booking country code such as us, gb, or it, or the full country name returned by Booking.com.

Booking traveler types are COUPLES, SOLO_TRAVELLERS, FAMILIES, GROUP_OF_FRIENDS and BUSINESS_TRAVELLERS. Availability depends on the source property and review.

Date filters (reviewedAfter, reviewedBefore, stayAfter, stayBefore) accept YYYY-MM-DD, ISO 8601, or a relative value counted back from the run start, such as 7 days, 2 weeks or 3 months. Relative values keep scheduled runs simple: "reviewedAfter": "7 days" always means the last week.

Reviews from a specific period

To collect the reviews of one month or season, even several years back, combine a reviewed date range with newest or oldest order:

{
  "hotelUrls": ["https://www.booking.com/hotel/us/ace-new-york.html"],
  "sortBy": "oldest",
  "reviewedAfter": "2024-03-01",
  "reviewedBefore": "2024-03-31",
  "maxReviewsPerHotel": 500,
  "maxPagesPerHotel": 100
}

The Actor first finds where the period starts in Booking.com's review list with a few page lookups, then reads it from there: oldest returns the period's earliest reviews first, newest its latest. Inside the period, maxPagesPerHotel is the number of pages (10 reviews each) it may read, and the walk stops by itself at the end of the period. The hotel_summary row shows the review page where the period started (dateRangeStartPage).

The other orders (most_relevant, score_desc, score_asc) are not sorted by date, so they read from the first page and only find reviews of the period that fall inside the scan window.

Monitoring new reviews

Set monitorName (for example ace-hotel-weekly) on a scheduled run to remember which reviews were delivered; every review row gets isNew. Add onlyNew: true to return and bill only reviews that earlier runs of the same monitor did not deliver.

Only reviews that were actually written to your dataset are remembered. If a run stops at your maximum charge limit, the reviews it could not deliver are returned by the next run instead of being skipped, and the monitor state is still saved.

Reliability design

Booking.com changes its web application over time, so the Actor does not hard-code a single hidden token or fixed review payload. It initializes the current hotel page, observes the live public review request generated by Booking.com, and then paginates using that session.

The run also includes:

• strict Booking.com hotel-URL validation
• duplicate hotel removal
• per-hotel review deduplication
• bounded browser and review-request timeouts
• bounded retries
• direct-first mode to avoid unnecessary proxy cost
• optional automatic Apify Proxy fallback if direct access is blocked
• source-page, per-hotel, and global result limits
• diagnostic rows instead of crashing the entire batch when one hotel fails
• maximum-charge handling for pay-per-event runs
• a clean stop shortly before the run timeout, with everything collected delivered; resurrecting the run (or a platform migration) continues where it stopped and never delivers or charges a review twice
• reviews written and charged in batches of 50

Output row types

review

A successful, billable Booking.com review.

hotel_summary

An optional free aggregate row for the property. It can contain total review count, rating categories, score distribution, language breakdown, and traveler-type breakdown.

review_insights

A free per-hotel row computed from the reviews returned for that hotel (after filters): average score, score distribution, reply rate, traveler-type and language distributions, top reviewer countries, average nights and the share of reviews with photos. Turn it off with includeReviewInsights: false.

status

A free informational row, for example when the selected filters find no or only some matching reviews inside the scan window or the requested date range (with the number of pages and reviews scanned and how to search deeper), or when Booking.com did not offer the requested sort order.

error

A free diagnostic row for an invalid input, an invalid/unavailable hotel source or another per-hotel failure. The error field says what happened and what to change; the run itself still succeeds.

Pricing

$0.001 per successfully emitted review (about $1.00 per 1,000 Booking.com reviews) plus a small start fee of $0.0001 per GB of run memory. Apify platform usage is included in the price. Subscribers on paid Apify plans pay less per review (Bronze −10%, Silver −15%, Gold and higher −20%). Optional add-ons: summary-only mode is $0.002 per hotel summary, and the residential proxy fallback (off by default) is $0.10 per residential attempt.

Only successful review rows trigger the review event. Summary, status, error, retries, duplicates, and reviews rejected by filters are free.

Spend controls

Use maxReviewsPerHotel, maxTotalReviews, and maxPagesPerHotel to bound work and result volume. Apify's maximum-total-charge setting is also respected when the Actor is monetized with pay-per-event pricing.

Limits and source behavior

Booking.com controls how many public reviews and fields are exposed for each property. Some fields, such as photos, room details, traveler type, or hotel replies, are absent on individual reviews and are returned empty rather than invented.

Very selective filters may require scanning more source pages than the number of emitted reviews. The Actor automatically allows extra scan room (about 8x the requested count), bounded by maxPagesPerHotel, and adds a free status row when it returns fewer reviews than requested. With a reviewed date range and newest or oldest order, it jumps to the period first and may read up to maxPagesPerHotel pages inside it.

Discovery from hotelSearchQueries and discoveryUrls is best effort: it reads the hotel links that Booking.com shows on the search page. Paste hotel URLs for the most predictable runs.

Responsible use

This Actor reads public hotel review information. Use reviewer names, review text, travel details, and other public data in accordance with applicable privacy, copyright, data-protection requirements, and Booking.com's applicable terms. Do not use the output to harass, deanonymize, or build sensitive profiles of reviewers.

Support

For a reproducible issue, provide the public Booking.com hotel URL, relevant filters, whether proxy mode was enabled, and the Apify run ID. Never include API tokens, proxy passwords, or private credentials.

Extended capabilities

• Discover hotel review targets from Booking destination/search pages or provide hotel URLs directly.
• Filter by review date, stay/check-in date, nights, room name, guest country/type, language, helpful votes, score, text, and hotel reply.
• Preserve hotel aggregates, distribution breakdowns, photos, stable monitoring IDs, and live sorter values.