Booking.com Scraper for Hotel Prices & Reviews

Extract Booking.com hotel search results with prices, ratings, review counts, addresses, coordinates, direct hotel URLs, filters, and optional room details.

Best for

• Revenue managers comparing hotel prices by date and destination
• Travel market analysts tracking ratings, review counts, and property supply
• Data teams building hotel dashboards, alerts, or enrichment pipelines
• Operators who need a small, repeatable Booking.com dataset instead of a broad crawl

Quick start

Use a small validation run first. It keeps cost and runtime predictable while you check the output columns.

{
  "destination": "Paris",
  "checkin": "2026-07-15",
  "checkout": "2026-07-16",
  "groupAdults": "2",
  "groupChildren": "0",
  "noRooms": "1",
  "maxHotels": 5,
  "batchSize": 1,
  "getDetails": false,
  "failOnNoResults": true,
  "timeout": 600,
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"],
    "apifyProxyCountry": "FR"
  }
}

Common workflows

• Price monitoring: run the same destination and dates daily or weekly, then compare price, rating, reviewCount, and hotelLink.
• Market mapping: collect hotels by city, district, star rating, review score, and distance from center.
• Room research: enable getDetails for selected hotels when you need room names, room prices, facilities, and more precise address fields.
• Travel lead enrichment: export hotel URLs, names, ratings, coordinates, and source metadata to a CRM or BI tool.

Useful input fields

Field	Use
destination	City or place to search, such as Paris or New York.
startUrls	Use direct Booking.com search URLs when you already have them.
checkin, checkout	Stay dates in YYYY-MM-DD format.
groupAdults, groupChildren, noRooms	Guest and room settings.
maxHotels	Keep low for validation runs, then increase gradually.
priceMin, priceMax, stars, minReviewScore	Market filters.
getDetails	Visits hotel pages for richer address and room data.
proxyConfiguration	Residential proxy is recommended for Booking.com.

Output fields

The dataset can include:

• hotelName
• hotelLink
• price
• rating
• reviewText
• reviewCount
• locationScore
• description
• address
• latitude
• longitude
• rooms
• detailFetched
• scrapedAt

When getDetails is enabled, the Actor may also save room names, capacity, prices, facilities, detailed address fields, breadcrumbs, nearby context, and review breakdown fields when Booking.com exposes them.

Settings that convert best

• Start with maxHotels: 5 and getDetails: false.
• Use getDetails: true only for smaller follow-up runs.
• Match the proxy country to the destination country when possible.
• Keep batchSize low for stable browser runs.
• Set failOnNoResults: true for scheduled monitoring, so empty runs are easy to detect.

Cost and runtime expectations

Booking.com uses dynamic pages and anti-bot controls, so browser and proxy setup cost more than a static HTML scraper. Small validation runs should finish first; large detailed runs should be split by city, date, or hotel subset. If a run is slow, reduce maxHotels, disable getDetails, or narrow filters before scaling.

Limitations

Booking.com can change layout, hide prices, localize fields, or require extra browser work. Prices and availability are time-sensitive and can differ by market, currency, date, guest count, and proxy location. Always keep source URLs and run timestamps when using the data for reporting.

Support

If a run returns unexpected data, open an issue from the Actor page with the input used, the run ID, and the result you expected.