Booking.com Hotels Scraper

Scrape Booking.com hotel search results by destination/dates/guests, and/or individual hotel pages by URL. Returns name, price, review score & count, address, amenities and more per hotel — using a real headless browser (Playwright) behind Apify residential proxy to actually pass Booking.com's AWS WAF anti-bot challenge, on both search results and hotel detail pages.

Why it's useful

Booking.com is one of the most valuable — and most protected — travel data sources. Track hotel prices for a destination and date range, monitor a specific property's rate/review score over time, or build a dataset of hotels for a city.

Input

{
  "destination": "Lisbon",
  "checkIn": "2026-11-10",
  "checkOut": "2026-11-12",
  "adults": 2,
  "maxItems": 30,
  "currency": "USD"
}

or, for specific properties:

{ "hotelUrls": ["https://www.booking.com/hotel/pt/altis-avenida.html"] }

• destination — place name (e.g. "Lisbon", "Paris, France"). Optional if hotelUrls is set.
• checkIn / checkOut — YYYY-MM-DD. Optional; Booking.com uses its own default dates if omitted. When set, the dates are also appended to each hotel URL so live room prices render for exactly those dates.
• adults — guest count (default 2).
• children — number of children (default 0).
• rooms — number of rooms to price (default 1).
• hotelUrls — specific hotel page URLs to scrape directly. Optional if destination is set. At least one of destination/hotelUrls is required.
• maxItems — cap on hotels returned from the destination search (paginated 25 at a time).
• currency — 3-letter code Booking.com should price in.
• language — Booking.com interface language (e.g. en-us, pt-br, es). Controls review words and amenity labels.
• proxyConfiguration — Apify Proxy settings. Residential proxies strongly recommended (see Notes).

Output

One item per hotel, source: "search" or source: "url":

{
  "source": "search",
  "name": "Altis Avenida Hotel",
  "url": "https://www.booking.com/hotel/pt/altis-avenida.html",
  "stars": 5,
  "price": 187,
  "currency": "USD",
  "price_for_nights_text": "US$374 for 2 nights",
  "taxes_and_charges": "+US$25 taxes and charges",
  "free_cancellation": true,
  "review_score": 8.9,
  "review_word": "Fabulous",
  "reviews_count": 3421,
  "address": "Lisbon, Portugal",
  "distance": "0.3 km from centre",
  "latitude": 38.7169,
  "longitude": -9.1399,
  "image": "https://cf.bstatic.com/...",
  "images": ["https://cf.bstatic.com/...", "..."],
  "badges": ["Breakfast included"],
  "room_config": "1 double bed"
}

Fields returned

Every search-result item carries: name, url, stars (1–5), price, currency, raw_price_text, price_for_nights_text, taxes_and_charges, free_cancellation, review_score, review_word, reviews_count, address, distance, latitude, longitude, image, images[], badges[], room_config, plus the echoed destination/checkIn/checkOut/adults.

Every hotel-page item (source: "url") carries all of the above-relevant fields plus:

• stars — official star classification (from JSON-LD starRating when present).
• address_details — structured { street, city, region, postal_code, country }.
• review_subscores — per-category guest scores: { cleanliness, comfort, location, facilities, staff, value_for_money, free_wifi, breakfast } (only the categories Booking shows).
• room_types[] — { name, price, currency, raw_price } for each listed room (best-effort; price is null if not shown for the selected dates).
• price_range, price_for_nights_text, taxes_and_charges — pricing context.
• free_cancellation / cancellation_text — cancellation policy.
• nearby[] — nearby landmarks / points of interest as { name, distance }.
• reviews_sample[] — sample guest reviews ({ rating, author, title, text, date }) from JSON-LD when present.
• amenities[] — facilities (merged from JSON-LD amenityFeature + the on-page facilities list).
• telephone, email, map_url — contact/map links from JSON-LD.
• description, images[], latitude/longitude.
• parsed_with — which extraction tier supplied the fields (json-ld+meta/dom, meta+dom, or dom), so you can judge confidence.

All enrichment fields default to null / [] / {} when Booking.com doesn't expose them for a given property — never fabricated.

Honesty on blocking

Every page load runs in a real headless browser behind a residential proxy session. If Booking.com's AWS WAF still serves a challenge/CAPTCHA page, the actor marks that proxy session bad and retries with a fresh session and a new residential IP (up to maxRequestRetries: 4). Only if every retry is still blocked does it emit { ..., error: "BLOCKED_OR_FAILED ..." } for that item — never fabricated hotel data. If a page loads cleanly but no results can be parsed (no matches, or Booking.com changed its markup), it says so explicitly instead of returning nothing silently.

Notes / limitations

• Booking.com fronts most pages with an AWS WAF managed challenge — a small JS page that must actually run in a browser to pass. This actor uses Playwright (a real headless Chromium) for exactly that reason, unlike a plain-HTTP approach which can spoof headers/TLS but can't execute the challenge JS — that's why a prior HTTP-only version of this actor could load search results (lighter-weight anti-bot) but got hotel detail pages blocked outright.
• Search parsing targets the data-testid attributes Booking.com's React app renders on result cards (title, price-and-discounted-price, review-score, address, distance). Hotel-page parsing prefers JSON-LD (schema.org Hotel) when present, then Open Graph/meta tags, then the same DOM markers — all reliably-present fields are extracted, nothing is guessed.
• A sign-in popup and/or cookie-consent banner are dismissed automatically if Booking.com shows one, before scraping.

⭐ Enjoying this Actor?

A quick rating/review helps others find it. Hotel-page items now include amenities, room types & prices, per-category review subscores, cancellation policy, nearby landmarks and sample reviews. Want multi-page hotel-review scraping or another field added? Open a ticket on the Issues tab.