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.
• adults — guest count (default 2).
• 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.
• 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",
  "price": 187,
  "currency": "USD",
  "review_score": 8.9,
  "review_word": "Fabulous",
  "reviews_count": 3421,
  "address": "Lisbon, Portugal",
  "distance": "0.3 km from centre",
  "image": "https://cf.bstatic.com/..."
}

Hotel-page items additionally include description, amenities, images, latitude/longitude and parsed_with (json-ld+meta/dom, meta+dom, or dom — which extraction tier actually supplied the fields, so you can judge confidence).

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. Want more fields (amenities, room types, cancellation policy) or multi-page hotel-review scraping added? Open a ticket on the Issues tab.