Booking.com Scraper: Hotel Rates, Room Types, and Availability

1.Data fields revenue and metasearch teams track

Rate shopping is only meaningful when comparisons are apples-to-apples: same check-in and check-out dates, same occupancy, same currency, captured within the same UTC window. The following fields represent the minimum viable dataset for parity monitoring and competitive intelligence. Capture them together in a single scrape — reconstructing missing fields from a second request risks rate drift.

Beyond raw price, the cancellation policy and breakfast flag materially affect total cost of stay comparisons. A nominally cheaper room with non-refundable terms and no breakfast is not equivalent to a slightly higher rate with free cancellation and breakfast included. Store both the headline price and the policy attributes.

• Hotel ID (data-hotel-id attribute or hotelId URL parameter)
• Property name and star rating
• Room type name and bed configuration (double, twin, king)
• Nightly rate, taxes and fees breakdown, and total stay price
• Currency code (differs by TLD and proxy geo)
• Cancellation policy: free cancellation deadline or non-refundable flag
• Breakfast included / excluded flag
• Rooms remaining count (urgency signals like '2 rooms left')
• Review score (0–10 scale) and total review count
• Genius loyalty discount badge and mobile-only rate flags
• Property type (hotel, apartment, hostel, guesthouse)
• Availability status (sold out vs bookable)

2.Booking.com URL patterns and required parameters

Booking.com hotel detail pages follow a predictable pattern: /hotel/{country_code}/{property-slug}.{locale}.html. The locale segment (en-gb, en-us, de-de) affects language of returned content but not necessarily currency — currency is driven by the proxy IP's country and the TLD. Always include date and occupancy parameters in the request URL; without them, Booking returns a calendar prompt rather than a rate table.

The hotel ID is embedded in the page as a data-hotel-id attribute on the main container and also appears in the URL parameter hotelId on some redirect flows. Capture it during your first scrape of a property and use it as the stable key for your rate time series — property slugs occasionally change after rebranding, but hotel IDs do not.

Search result URLs use searchresults.html with a destination string in the ss parameter. These pages are significantly more protected than hotel detail pages and should be used only for initial property discovery, not for ongoing rate collection. Once you have a hotel's detail URL, scrape that directly.

• Hotel detail: https://www.booking.com/hotel/us/the-standard-high-line.en-gb.html
• With dates and occupancy: ...?checkin=2025-08-10&checkout=2025-08-12&group_adults=2&no_rooms=1
• Search results: https://www.booking.com/searchresults.html?ss=Paris&checkin=2025-09-01&checkout=2025-09-03&group_adults=2
• Country TLDs: booking.com (USD/GBP), booking.de (EUR) — currency varies by TLD and proxy geo
• Hotel ID in DOM: data-hotel-id on main property container
• Locale variants: .en-gb.html, .en-us.html, .de-de.html — affects content language
• Currency override: &selected_currency=EUR (not always honored; proxy geo takes precedence)

3.Rate table, room row, and review DOM selectors

Booking.com's rate table renders inside a table.hprt-table element. Each room type occupies a tr[data-block-id] row or, in the newer React-based layout, a div with a data-testid attribute. The room type name appears in td.hprt-table-cell-roomtype, and the price in span.prco-valign-middle-helper or div.bui-price-display__value depending on which A/B variant the session receives. Capture both selectors and fall back gracefully.

Rates are JavaScript-rendered — the rate table is populated after the page loads and date parameters are processed client-side. A request without checkin/checkout in the URL will receive a page with an empty rate section and a date picker prompt. Always embed dates in the URL rather than relying on JavaScript interaction to set them.

The review score badge is in div.bui-review-score__badge (the numeric score) and div.bui-review-score__text (the count and label). Property description text sits in div#property_description_content. Amenity lists use ul.hp-desc-highlighted-amenities for the headline features and a separate expandable section for the full list.

For the newer Booking.com layout (progressively rolling out), data-testid attributes are more stable than class names. Key testids: data-testid='title' for hotel name in search results, data-testid='price-and-discounted-price' for the price chip, data-testid='review-score' for the score container, and data-testid='title-link' for the anchor to the hotel detail page.

4.Akamai bot management and session-dependent pricing

Booking.com deploys Akamai Bot Manager across its entire domain. Datacenter IP ranges are fingerprinted and either challenged with an interstitial, served a CAPTCHA, or silently shown incorrect rates — the silent rate manipulation is the hardest failure mode to detect because the response returns HTTP 200 with plausible-looking but wrong prices.

Pricing on Booking.com is personalized along several dimensions simultaneously: the geographic origin of the request IP, the browser fingerprint and device type, the session's cookie history (repeat visits to a property page can trigger urgency pricing), and the guest's Genius loyalty tier if the session carries a logged-in cookie. For rate intelligence work, you need to control all of these variables and record them alongside every price observation.

Search result pages (searchresults.html) trigger Akamai challenges at much lower request rates than hotel detail pages. Use search only for property discovery — scrape a destination once to build a list of hotel detail URLs, then run all ongoing rate collection against those detail URLs directly.

• Akamai Bot Manager: interstitial challenge, CAPTCHA, or silent rate distortion on datacenter IPs
• Geo-personalized pricing: proxy country must match the guest nationality you are simulating
• Session cookie binding: rate quotes are tied to session state; use session_id for multi-step flows
• CAPTCHA escalation on searchresults.html pagination beyond page 2–3
• Mobile vs desktop rate differences: some properties show lower rates to mobile user agents
• Genius discount rates: only visible to sessions carrying a logged-in Genius account cookie
• Silent block detection: compare returned prices against a known baseline to detect distortion

5.Scraping a hotel detail page with dates

Use mode js_rendering because the rate table is populated by JavaScript after page load. Set js_wait_selector to table.hprt-table so the request waits until the rate grid is present in the DOM before extracting. A residential proxy matching the guest nationality you are simulating is essential — use proxy residential:us for US-origin pricing, residential:gb for UK, and so on.

The css_selectors map extracts the core fields in a single request. The prices selector targets the per-night price chip; cancellation targets the policy cell in the rate table. If a room is sold out, the cancellation cell will be absent and prices will return an empty array for that row — handle this in your parser.

Store the proxy country, scrape timestamp (UTC), and the full URL including date parameters alongside every price record. Without these, rate time series are not comparable across runs.

1234567891011121314151617181920{
  "url": "https://www.booking.com/hotel/us/the-standard-high-line.en-gb.html?checkin=2025-08-10&checkout=2025-08-12&group_adults=2&no_rooms=1&selected_currency=USD",
  "mode": "js_rendering",
  "output_format": "css_extractor",
  "proxy": "residential:us",
  "js_wait_selector": "table.hprt-table",
  "js_wait_timeout": 15000,
  "css_selectors": {
    "hotel_name": "h2.pp-header__title",
    "hotel_id": "[data-hotel-id]",
    "review_score": "div.bui-review-score__badge",
    "review_count": "div.bui-review-score__text",
    "address": "span.hp_address_subtitle",
    "room_types": "td.hprt-table-cell-roomtype",
    "prices": "span.prco-valign-middle-helper",
    "cancellation_policies": "td.hprt-table-cell-conditions",
    "breakfast_flags": "td.hprt-table-cell-meal",
    "rooms_remaining": "td.hprt-table-cell-rooms-left"
  }
}

6.Search results for property discovery

Search result pages carry higher Akamai friction than hotel detail pages. Use them only for the initial discovery pass — scrape a destination once to collect hotel names, IDs, and detail URLs, then switch all ongoing rate collection to individual hotel detail pages. Avoid paginating search results beyond the first two pages in a single session.

The data-testid selectors below target Booking's newer React layout, which is more stable across redesigns than the legacy class-based selectors. The links selector returns relative paths — prepend https://www.booking.com to construct full hotel detail URLs.

Use a residential proxy matching the destination country to get locally relevant results and avoid geo-mismatch challenges. For Amsterdam searches, residential:nl returns results in EUR with locally accurate availability.

1234567891011121314{
  "url": "https://www.booking.com/searchresults.html?ss=Amsterdam&checkin=2025-09-01&checkout=2025-09-03&group_adults=2&no_rooms=1&order=price",
  "mode": "auto",
  "output_format": "css_extractor",
  "enable_solver": true,
  "proxy": "residential:nl",
  "css_selectors": {
    "hotel_names": "div[data-testid='title']",
    "prices": "span[data-testid='price-and-discounted-price']",
    "review_scores": "div[data-testid='review-score'] div",
    "hotel_links": "a[data-testid='title-link']",
    "property_types": "span[data-testid='recommended-units']"
  }
}

7.Handling Akamai bot management on Booking.com

Akamai Bot Manager on Booking.com operates in several modes depending on the request path and traffic pattern. Hotel detail pages with a residential proxy and mode auto typically resolve without a visible challenge — Akamai's sensor data collection runs client-side and the OmniScrape Web Unlocker handles the resulting cookie and header requirements. Search result pages and pagination are more aggressive and benefit from enable_solver: true to resolve interstitials.

The most common failure mode is not an HTTP error but a silently degraded response: the rate table renders but shows prices that are 20–40% higher than real rates, or shows only the most expensive room categories. Detect this by maintaining a baseline of known prices for a set of sentinel properties and alerting when scraped values deviate significantly from the baseline.

If the rate table selector (table.hprt-table) is not found after js_wait_timeout, the session likely received a CAPTCHA or a date-prompt page. Check body.data.content for the string 'robot' or 'verify' to distinguish a bot challenge from a legitimate empty-availability response. For detailed Akamai challenge patterns and header strategies, see Akamai bypass.

Rotate session_id between hotel detail requests rather than reusing a single session across many properties. A session that visits dozens of hotel pages in sequence accumulates behavioral signals that Akamai scores as bot-like. Fresh sessions per property — or per small batch — keep the fingerprint clean.

8.Rate parity monitoring across OTAs

Rate parity monitoring compares a hotel's Booking.com rate against the same property's rate on Expedia, Hotels.com, and the hotel's own direct booking site — for identical dates, occupancy, and room type, captured within the same UTC minute. Even a two-minute gap between OTA scrapes can introduce rate drift from dynamic pricing updates.

Structure your parity pipeline around a canonical room type identifier. Booking.com room type names are free text and vary by property; normalize them to a canonical category (standard double, deluxe king, suite) using fuzzy matching or a lookup table maintained per property. Without normalization, you will compare a 'Superior Room with Garden View' on Booking against a 'Deluxe Room' on Expedia and produce meaningless parity alerts.

Store the proxy country and currency code with every rate record. A rate captured via residential:us in USD is not directly comparable to one captured via residential:gb in GBP — convert to a common currency at the exchange rate at scrape time, not at analysis time. For alerting infrastructure and storage patterns, see price monitoring web scraping.

Parity violations fall into two categories: the hotel is selling cheaper on Booking than on its own site (a terms violation in most OTA contracts), or a third-party reseller is undercutting the hotel's own Booking rate. The second case requires scraping not just Booking's standard search but also Booking's 'Deals' and 'Genius' rate surfaces, which require authenticated sessions.

9.Legal and contractual considerations

Booking.com's terms of service explicitly prohibit unauthorized automated access and the commercial redistribution of scraped rate data. Building a public rate API that republishes Booking prices is high legal and contractual risk. Metasearch operators and OTA aggregators that display Booking rates commercially do so under content partnership agreements, not through scraping.

Internal revenue management use cases — a hotel monitoring its own rates and competitors on the platform it sells through — occupy a different risk profile. The data subject is your own property's pricing, and the use is operational rather than redistributive. That said, Booking.com does not formally carve out this use case in its terms, so the legal exposure is not zero.

Academic research and journalism involving Booking.com pricing have proceeded under fair use arguments in some jurisdictions. The EU's Digital Markets Act and related regulations are creating ongoing legal uncertainty around OTA data access rights. Consult qualified legal counsel before building any commercial system that depends on Booking.com scraped data.