Booking.com Room-Level Hotel Price Scraper
Pricing
from $3.50 / 1,000 results
Scrape and track Booking.com hotel prices by room type and date, up to 365 days ahead. Extract rate options, availability, sold-out dates, meal plans, discounts, refundable rates, and geo-pricing. Built for hotel revenue management and competitive rate analysis. Export JSON, CSV, Excel, or HTML.
Every release of the Booking.com Room-Level Price Tracker, newest first. The three most recent also appear in the README.
market_median_rate and the gap columns in market_summary are unchangedtaxes_on_top in market_summary: true when every rate on sale that night adds tax on top, false when every one has it inside, empty when they disagree or do not saycancellation_policy, is_refundable, max_nights_bookable, max_rooms_per_booking, los_prices, rooms_length_restricted, lead_in_rate and the includeLosAnalysis input) moved out: Apify's dataset screens and AI clients reading the Actor through MCP show these textsmarket_summary counted only what was on sale: sold_out_ratio 0, demand_pressure "normal", and the reason "every room type available" — on nights the property was nearly full. With tracking off, room_types_offered, room_types_sold_out, sold_out_ratio and demand_pressure are now left empty, and the reason says whystartDate meant today on Apify's servers, which run on UTC. Perth is UTC+8: the 2026-09-22 run at 22:57 UTC was 06:57 on the 23rd there, and the first night it asked for — the 22nd — had already gone. Booking answered the only way it can: Great Eastern with "No rooms on the page", Flag Motor Lodge, ibis and Sanno with every room sold out. Those false sell-outs went into demand_pressure, the compset and the daily digest. The window now starts on today at the hotel, read from the hotel's own longitude before any date is scraped — same number of nights, one hour of margin so a night still on sale is never skipped. lead_time_days counts from that date too, so tonight reads 0hotel_longitude) instead of UTC's, so it catches exactly thisActor.call hands back the run whatever became of it, and v2.16.0 did not look at its status. The log now says NOT sent, with the Send Email run's status and id, and points to the webhook field as another way to get the digest by email (a Make or Zapier webhook). An address the field cannot use is now said too, instead of being skipped silentlyThe morning read of a run, in one screen — and a correction to three fields that have been misread since v2.5.3.
myHotelUrl is set): cheapest or dearest on how many nights, the nights you sit furthest above and below the market median, the nights where most competitors are sold out while you still sell (room to move), and the nights you are sold outmax_nights_bookable counts rooms, not nights. Booking's quantity dropdown is the proof: a saved page offers "1 (US$130)", "2 (US$260)" … "5 (US$649)", and the page data this field is read from (b_nr_stays, b_stay_prices) holds exactly those prices. On the 2026-09-22 Flag Motor Lodge run it equalled the dropdown on every room (2/2, 6/6, 8/8, 4/4). The name stays so nothing that reads it breaks; its description, its column label and everything built on it are corrected — and it now backs up max_rooms_per_booking when the dropdown cannot be readmarket_summary.restricted_ratio said "priced for a single night only". It is the share of room types down to their last room. demand_pressure_reason now says so, and the Market by date columns read Last-room types / Last-room share. demand_pressure itself never used it and still does notbooking_hotel_id and twelve other columns, and a night the whole property sold out carried no weekday and no lead time, so it fell out of every weekday or booking-window view. Every sold-out row now has every column of a priced row, and a test compares themincludeLosAnalysis was not a length-of-stay analysis — los_prices are Booking's prices for 1, 2, 3… rooms at once. It was also always empty: it read a key the room never had. It now reads the selected rate's own ladder, has_los_discount means a multi-room discount, and the input is titled Include multi-room pricesFound by putting a live export beside another scraper's output for the same four Perth motels and the same night. The prices matched to the cent where the party and date matched. What was around the price did not.
free_cancellation_until was empty on every row — 0 of 240 on the 2026-09-20 Perth run. The date was parsed from the whole row, in US order only ("October 7"), while every page loads in British English ("7 October 2026"). Worse, where it did match it could take the wrong date: a cell reading "Free cancellation before October 7, 2026 • Pay nothing until October 5, 2026" published 5 October — the payment date. The date now comes from Booking's cancellation sentence alone, in British, US and French wording, with or without a timefree_cancellation_days_before_arrival — the policy as one number. "Free cancellation before 7 October" on a 9 October stay is 2: Booking's own "cancel for free until 2 days before arrival". The date moves with every check-in; the number compares properties at a glancemax_rooms_per_booking gave every room the page's largest number. It read every quantity dropdown in the room table instead of the room's own, so Sanno's Standard King showed 10 beside its own "7 left" badge, and 18 rows of that export offered more rooms than Booking said were left. It now reads the room's own dropdown — the number other tools publish as number_available_at_this_pricebookable_now_label, in Rate shopping V2 as "Bookable now". Booking's dropdown offers min(rooms still on sale, the property's per-booking ceiling), so the label says only what the page proves: 4 left when the room's dropdown stops below another room's on the same page (or Booking shows its badge), 10+ at the page's top — at least that many. On the other scraper's output, one motel's eight rooms read 1, 1, 1, 2, 4, 6, 7 and 10 that nightcompset_rank and every gap were built on those numberslowest_bookable_rate and lowest_bookable_terms on every room. nightly_total_price stays the like-for-like rate; this is the lead-in, and market_summary.lead_in_rate is now built on it. The rate_selection_reason sentence names the cheaper rate when the headline is not the cheapestcompset_rank, market_median_rate and the gap columns live in the market_summary dataset, which only Storage showed. The Output tab now links Market by date and Rate shopping V2 directlyrequested_children_agesrooms_left, which is still filled only by Booking's own "Only N left" badgeIf you upgraded to v2.14.0, take this one. A run that shows nothing for fifteen minutes is its own kind of broken, whatever order it eventually writes in.
hotelUrls, dates ascending, rooms in Booking.com's page order. What changed is that only the hotels still waiting hold anything, which also shrinks what a killed run can loseSame input, same screen. Every time.
sort_key has always fixed it for anyone who sorts, and nobody sorts a screen they expect to already be in orderhotelUrls — dates ascending, rooms in Booking.com's own page order, the same layout every run. Scraping stays concurrent; only the writing is ordered, and a hotel waiting its turn releases its concurrency slot so another hotel can scrape in itnightly_total_price is Booking.com's displayed price: taxes it folds into the price are in that number, taxes it charges on top are not. On a live run of four Perth motels, 59% of rows read ⚠️ Additional taxes reported — 176 shown, 17.64 GST added at checkout — under a header telling the reader 176 was final. The column beside it exists to say which case you are in; the header must not answer for it. It now reads "Rate (as shown)", and the field's own description says which taxes are inside ittaxes_excluded is published raw for anyone who knows their market's rule. A test now keeps both decisions from driftingNothing on an existing job's screen changes. The rebuilt screen is now opt-in.
is_my_hotel, the exact rate. Same dataset, one tab across. ?view=rate_shopping_v2 on the APIavailability_status, an enum of four real availability states — there is no honest value in it for "this date was never scraped", and widening that enum would change a token scripts filter on. So on the original view a failed row stays as sparse as it always was. Reading why a row is empty is one of the reasons to move a job to V2⚠️ Not scraped — Booking.com served a block page — a named, visible signal rather than a fearstartDate is a fixed date, so a task that runs every day keeps asking for the same window while the window slides behind it. A night that has already happened cannot be sold, and Booking.com answers the only way it can — nothing available. In a compset that is not harmless: those nights inflate sold_out_ratio, which is what demand_pressure is computed from, so a stale window reads as a market under pressure. Leave startDate empty and the window moves with the runcompset_rank, market_median_rate and gap_to_market_median all come back empty. It was warned about in the log, and a real user was found running five separate one-hotel tasks: nobody reads the log of a run whose card says Succeeded. The run's status line now ends with "⚠️ 1 property only — no rate shop", RUN_REPORT.json explains the fix, and a new one_property_only flag lets a task or an alert branch on it without matching on proseFirst clean full export: 335 rows, 5 properties, 14 dates, 0 broken.
audit_export.py reads the CSV you actually download. It only spoke JSON, and Apify's default download is CSV — an auditor nobody can point at their file is an auditor nobody runs. It now reads .csv, .tsv, .json and .jsonl, turns "" back into null, true into a boolean and 83 into a number, and strips the byte-order mark Apify writes (without which the first column comes back named \ufeff"hotel_name_clean" and every rule that reads the hotel name goes quietly blind)⚫ Sold out — no room list, with the reason on it. It is marked sold out, not failed, and it stays out of the market summary so a redirect can never invent a room count
python3 tools/audit_export.py export.json— nineteen rules, one second, exit code 1 if anything is broken. Run it after every run before you trust a number.
🟢 Available and carried no rate. Riad Gallery 49's Standard Single Room — a single room, on sale, just never for two people. Green beside an empty rate cell teaches a reader to distrust the column. Those rows now read ⚪ No rate for 2 guests. availability_status is unchanged, so anything filtering on it keeps workingDouble Room (#47398910). Only where it is neededThe first clean run since the driver fix. Reading its 50 rows found four defects, and every one of them came from the data, not from a guess.
✦ New — two of three properties compared against nothing. The room-night key was Booking's hotel id, or the URL slug if the id was not read — so the key silently changed shape whenever the metadata read missed, and nothing matched. It is keyed on the slug now, which comes from the URL you give us and cannot fail. Your existing history is carried over, because a Booking room id identifies a room-night on its own; only rooms Booking never gave an id to restart, onceriad-kech-one-amp-spa on the row that failed, Riad Kech One & Spa on the rows that worked — the same hotel, sorted to two different places. Rows that carry no data are now held until the property's name is known, which on any run with one good date is always; if a property never gets that far, the slug is turned into a name a person can read. Five places used to build these rows by hand, and they had drifted: two never set the property's clean name at all, two never said which kind of failure it wasrow["is_refundable"] answered on one and raised on the other. One shape now⚫ Sold out beside ✦ New. A room seen for the first time gets "new" whether or not it had a price. Sold out is the whole story of that row🔴 If runs keep dying partway through with
Connection closed while reading from the driver, this is the fix. The proxy was never the cause.
_CRSession._onMessage → assert(): Assertion error (29 of 33 pages lost) and Invalid InterceptionId (63 of 70 pages lost). The second run had a verified residential proxy, which is how we know the proxy had nothing to do with itpage.route(..., abort) — request interception. Chromium pauses every matching request, hands it to Playwright's Node process, and waits for a verdict; each pause carries an id. When a navigation times out or is cancelled mid-flight, those ids are released while verdicts for them are still in the pipe — and the driver's answer to a verdict for an id it no longer knows is assert(), which ends the Node process. That is not an error any try can catch: process gone, browser gone, all three parallel hotels gone with itNetwork.setBlockedURLs). The same images, fonts and trackers are dropped, so the saving on your proxy bill is unchanged — but it happens inside the browser, with no pause, no round trip and nothing left to assert on. A test drives a real browser at a real page and checks that the image and the tracker never leave it, and that the JavaScript doesbrowser_restarts in RUN_REPORT.json, so a run that recovered on its own says so plainly🔴 If a run returned rows carrying a hotel name, a date and nothing else, this is the fix. Upgrade and re-run — and keep the proxy on.
status and error_message are not columns in the Rate shopping view, so they arrived as empty lines. Every failure row now says what happened in the Availability column: ⚠️ Not scraped — our browser died mid-run. And the Full detail view gained Row status, Failure type and What failed, which it never haderror_type: page — Booking.com's fault — when Booking.com had answered perfectly wellcrashed verdict now says what actually happenedfailures_browser in RUN_REPORT.json, and in the summary line: 29 failed (0 proxy, 5 page, 24 browser). Three different problems, three different fixesThird time on this field, and the last. It is no longer read from prose at all.
🔴 Il nous reste 1 option — option, not chambre. That is why the original loose regex appeared to work, and why tightening it to demand the word room (v2.12.0) made rooms_left null on every row of a live run. Both versions were guessing at wording-scarcity_indicator-pss_scarcity_1_left — so wording, language and Booking's A/B tests all stop mattering0-1 on the riad and 0-5 on every room of a motel, stocked or not. It is a ceiling, so it gets its own honest field, max_rooms_per_booking, and can never become rooms_left1 / exact / 🔴 Only 1 room left and the motel reports null / hidden / 🟢 Available — so neither direction of this mistake can return47398912 now reads "Standard Single Room" on every date it appears, where it flipped to "Double or Twin Room" on one date before. became_sold_out fires with a real previous price behind itrooms_left came back null on every row of a live run. The patterns now also accept that wording — and stay safe because the discriminator is "on our site", which the scarcity badge says and the rate dropdown ("3 options") never does. Still no bare-number pattern anywhere✦ New, then normal[data-room-id] sweep, then zipped them with ids[rooms.length]. Nothing keeps two DOM scans in the same order, and they were not: room 47398912 came back as "Standard Single Room" on three dates and "Double or Twin Room" on the fourth. That id is part of the price-history key, so a shifted pairing compares one room against a different one and invents availability transitions. Each id is now read from the href of the anchor carrying the name, and a name with no id of its own gets null — a wrong id is worse than noneis_my_hotel read false on every row when myHotelUrl was simply left empty. "This is not your hotel" and "you never said which one is" are different answers; the second one is nullphoto_count still fell back to a false 0 in four room buildersmyHotelUrl, new field is_my_hotel. Paste your own property's URL (and keep it in hotelUrls too) and every row of yours is flagged. Sort your rates to the top, and tell an AI "my hotel is the row where is_my_hotel is true" instead of letting it match a name it can get wrong. Matching ignores query strings and language suffixes, so any form of the URL workssort_key on every row — hotel → stay date → room → room id. Rows reach the dataset in the order the scrape finishes them and hotels run in parallel, so a room that was row 1 yesterday can be row 4 today. Sorting on this one column lines up any two exports. Nothing the Actor computes was ever affected — every comparison matches on identity, never on position — and the movement columns exist precisely so you no longer have to diff two exports by handcompset_rank, market_median_rate and every gap column empty — prices with nothing to compare them to. The log says so instead of leaving you to notice the blank columnsmarket_summary row now carries compset_expected, compset_observed, compset_coverage and a plain coverage_warning naming how many properties are missing from that date's figureserror_type: "browser" instead of blaming Booking.com for a browser that died on our sidedemand_pressure no longer announces demand off an unverified field. It used to read "high" on restricted_ratio alone — and max_nights_bookable was 1 on 69% of live rows, so nearly every date would have claimed high demand. The restriction count is still published and still named in the reason; it just cannot set the level. Only rooms Booking.com says it cannot sell move the needle nowai_input view — 37 columns, about a quarter of the tokens of a full export. The columns a pricing question needs, with the error rows kept on purpose: a model that cannot see which hotel-dates failed will read a missing competitor as a market that moved. The README now carries the full prompt to paste with iterror_type: "crash" and three undeclared record_type valuesThree days of real runs across five properties, then a line-by-line audit of the export. Every item below was verified on the data, not guessed.
rooms_left was never a room count — again. It equalled the number of priced stay lengths in 193 of 193 rows: a perfect diagonal, 1↔1 through 5↔5. A pattern was matching Booking's rate dropdown (3 options) and then stamping stock_confidence: exact on it. Rooms bookable for one night only were being published as 🔴 Only 1 room left — 189 of 336 rows were red for a reason that had nothing to do with inventory. Every scarcity pattern must now name a room, and four tests read them out of the source so this cannot return a fourth time✅ Taxes included was wrong on every row that carried it. All 27 also had a positive taxes_excluded — VAT inside the price, city tax on top. There is a fourth state now: ⚠️ Part included, more on top. Only ✅ means finalbecame_sold_out and came_back appeared zero times in three runs on a compset where 40% of rows were sold out. Both paths now record the transitionnightly_total_price_exact. Booking prints US$103; its own data says 102.80. The two differed on 173 of 173 rows. The displayed figure stays the headline — it is what a guest is quoted — with the exact one beside itmax_guests is labelled Rate fits up to: a 2-adult search matched a rate sold for 3 or 4 guests on 44 of 173 rows, so it never proved the quote was priced for two. And max_nights_bookable is marked unverified — every multi-night stay_prices value was exactly the one-night price × the nights, which is extrapolation, not a quote🔴 If a run reported
Unexpected: Schema validation failedon every date, this is the fix. Upgrade and re-run; no input change is needed.
🐞 Fixed: tax_clarity_label gained a ✅ / ⚠️ mark in v2.9.5 and the schema still listed the unmarked values. The field declares an enum, so Apify rejected every room row and every date came back as an error
✅ The guard that should have caught it has been replaced. The check written after the first schema outage compared each value's type and nothing else — hand-rolled, and blind to enum, pattern, minimum and every other rule Apify actually enforces. The tests now hand each pushed row to a real JSON Schema validator, the same way the platform does
✅ And it now runs the second run too. Every movement column is null on a first run by design, so a first-run test never exercised one of them with a real value. The harness replays the page with price history in place, marks yesterday down 10%, and validates the rows that come back — a move, a stability clock and a baseline, all checked
✅ Price tracking has its own section on the input form, and it is the first one. It was buried under Performance, between the length-of-stay toggle and the wholesale-rates one — a headline feature filed under speed settings. It now sits directly beneath Track Sold-Out Rooms, ahead of Search Configuration, with a heading that states the one thing that matters: run #1 has nothing to compare against, so save the input as a task and schedule it daily
✅ Price history store name says it is optional, because nobody could tell. Leave it empty and it fills itself in; it exists only for running two jobs whose histories must not mix
✅ Every toggle now says what you get, after saying what it does. The descriptions explained their mechanism and stopped there, leaving the reader to work out why they would want it. The mechanism stays — it is the part you need to operate the thing — and the answer follows it: a sold-out competitor room is the date filling up before anyone reprices; a wholesale rate is what your guest actually compares you against on that channel
✅ Tax basis moved out of the glance zone, into the tax block. It was pinned beside the rate so a price could never be read as final when it is not — but it reads "Taxes included" on run after run, and a constant column is the one thing the glance zone cannot afford
✅ …and the safety no longer depends on its position. tax_clarity_label now carries a mark: ✅ Taxes included, ⚠️ Additional taxes reported, ⚠️ Final cost not confirmed. A warning sign is visible from the far side of a wide table where a word is not. The wording after the mark is unchanged, so anything matching on the text ("Additional taxes reported" in label) still matches; price_basis remains the unmarked machine token
📖 The movement columns are documented properly — a new README section says, for each of Move, Δ Rate, Δ %, Held (d), Avail. move and Rate spread: what it is, what it protects you from, and whether it needs a previous run at all (rate_spread does not — it works on run #1)
📖 "It only works on a schedule" is now impossible to miss — it is in the hero, it is step 4 of the Quick start, and the section explains why run #1 says ✦ New and why the schedule must be daily and at the same hour
📖 Documented what starts a fresh history — changing occupancy, currency or proxy country changes the identity of the quote, so the comparison restarts rather than inventing a move out of a changed input
📖 README cleaned up. The body had drifted into engineering notes — version numbers in the middle of a field description, paragraphs explaining why a column sits where it sits, a views table cell that had grown into a design memo. It reads as a product page again; the history stays down here in the changelog, which is what it is for
Column layout only. No field left a record: everything below is still on every row, in Full detail, in the CSV/Excel exports and at the API endpoint.
room_photo_url stays on every recordRooms left loses its column — availability_label already prints the number inline (🔴 Only 2 rooms left) when Booking states one, so the column was a second copy of a fact that was either already on screen or absentStatus (raw) and Sold out dropped from the view — availability_label says both, in wordsMax nights moved up, beside Guests and ahead of the cancellation block: how many guests and how many nights a rate will take decide whether it is comparable at all, so they are read before its termsMarket and Cur. now sit directly after Net rate / Taxes & fees — a rate is only comparable inside its own market and currency, so the cohort travels with the price breakdown instead of sitting at the far end of the rowTwo machine tokens, a fabricated-looking blank and a timestamp that was never a timestamp. All four were costing reading time on the one screen this Actor exists for.
low_availability_urgent is a token a script filters on — four of them cannot be told apart at a glance in a table of 1,800 rows. availability_label shows the same fact as 🟢 Available, 🟠 Low availability, 🔴 Only 2 rooms left, ⚫ Sold out, and folds in the room count when Booking.com actually states one (never a made-up number). availability_status is still on the row, in the tail, so nothing scripted breaksprice_move_label reads ▲ +8 (+5.56%), ▼ -14 (-9.21%), – Unchanged, ✦ New. Null for a sold-out room, which has no price move. price_direction stays in the tail for the same reasonrooms_left is back beside availability, where it is read when Booking does state a count — it was exiled to the tail in v2.5.3 because it is blank on most rows, and the inline count in the label means that blank is no longer the only signalroom_photo_url), rendered inline in the table. "Superior Queen" at six properties is six different rooms. The URL comes out of the page's own embedded state — no image is ever downloaded, so the run does not get slower — and it is published at the size Booking.com itself serves, never a rewritten one that could 404photo_count is a real number. It reported 0 on every row until v2.5.3 and null ever since, because images are blocked and there is nothing in the DOM to count. The same embedded state lists every room photo, so the count is now a factStay date and Cur. — the currency is one value for the whole run and moved to the tail, while the two dates are what you scroll looking for22:00:00 UTC. Apify's date format turns a plain 2026-10-05 into a full instant in a timezone the value never had — unreadable, and off by a day at the edges. Date-only columns are rendered verbatim now; only scrape_timestamp, which really is an instant, keeps the formatPrev. capture dropped from the Rate shopping view — a bare date next to Gap (d), which already says the same thing as a number you can sort. Still on every record and in Full detailNo field was removed from a single record. This is about what the default screen shows first, and about the Actor doing one job instead of three.
nightly_base_price (Net rate) and taxes_and_fees_total (Taxes & fees) used to sit in front of the rate so the price read the way it is quoted — net → tax → total. In practice nobody re-adds the sum: the total already contains both, and it is the number the decision is made on. The breakdown moved right, next to primary_tax_label and total_stay_price, and reads in the same order where it sitsdays_since_price_change (Held: has this competitor moved in the last twelve days, or are they parked?) and rate_spread (how wide their rate ladder is on this date — the depth of their fencing). Both were already computed and already in the view; they were just too far right to be read?fields= rather than a fixed view — same result, any column set you want, documented under Handing the rate feed to an LLM🔴 If a run reported
Unexpected: Schema validation failedon every date, this is the fix. Upgrade and re-run; no input change is needed.
photo_count was declared integer but sent as null. v2.5.3 correctly stopped reporting a false 0 for a count that images-blocked runs can never take — but the dataset schema was not updated with it, so Apify rejected every room row and every date came back as an error. It is ["integer", "null"] now, which is what the value has meant since v2.5.3hotel_sustainability_certified — it is read from the property metadata, which is an empty object whenever the metadata visit fails, so any such run would have hit the identical walltests/test_rows_match_the_schema.py validates rows against the declared schema two ways: statically at every push site (covering sold-out rows), and by running the real pipeline against the saved fixture page and checking every field of every row it produces. Reverting either fix now fails three tests locally instead of failing a paid run. tools/row_harness.py exposes the same path for manual inspectionThe question a rate shop exists to answer — who moved, and by how much? — could not be answered at all: every run was a snapshot with no memory of the last one.
price_direction (up / down / unchanged / new), price_change, price_change_pct, previous_price, days_since_previous_capture, days_since_price_change, first_seen_price / first_seen_at, and availability_change (became_sold_out / came_back). They sit immediately beside the rate in the Rate shopping viewtrackPriceChanges (default on) and historyStoreNamenew. Save your input as a task and run it dailynull deltas and never 0; the age of the baseline is published so a stale comparison cannot read as "since yesterday"; a sold-out room reports an availability change and no price change, and its last known price is kept so it can be compared again when it comes back on saleis_genius_ratehotel_star_rating and hotel_review_score moved to the tail. The person running a rate shop has already chosen their compset and knows those properties — the columns are reference for whoever receives the export, not part of the decision, and they were pushing the rate to the righttax_clarity_label still sits immediately right of the rate, and availability_status before every price column — both pinned by tests, so a future reorder cannot quietly break themis_genius_rate — this one changes decisions. Whether the reported rate is a Booking.com Genius (member) rate existed only nested inside primary_rate_option, where a flat table cannot read it. A revenue manager comparing their public rate against a competitor's Genius rate "matches" a price that was never public. It is now a top-level column, on the Rate shopping screenhotel_star_rating and hotel_review_score are now columns 2 and 3 of Rate shopping. Comparing rates without knowing whether the competitor is a 3-star or your 4-star is how a compset produces a bad matchmax_guests on the Rate shopping screen — a 2-guest rate and a 3-guest rate are not comparable, and the column that said so (price_basis) was a machine stringmarket_summary — with several properties in one run, every property-night now carries compset_rank / compset_size, price_position (cheapest → most_expensive), gap_to_market_median, gap_to_cheapest, market_median_rate and market_lead_in_rate. Ranking is on lead-in rate, same night, same occupancy. A sold-out property takes no rank and does not move the median — no price is not a high price. With one property in the run every comparison field is null, because rank 1 of 1 is not informationmarket_summary is now written when the cohort finishes, not per date, because ranking a property against a half-scraped compset would be wrong. Room rows are unaffected — they are still written as each date completesavailability_status sits immediately before the rate so a blank price is explained by the cell on its left — one column for availability instead of four, with rooms_left / stock_confidence / is_sold_out moved right (mostly empty since v2.5.3) and the machine-readable price_basis dropped in favour of tax_clarity_label, which says the same thing in wordsv2.5.3 removed a fake scarcity number. This puts real demand signal in its place — all of it derived from what the page already states, with no extra requests and no history required.
market_summary dataset — one row per property per night, in its own storage (Storage → Datasets → market_summary). Carries sold_out_ratio (share of the property's room types it cannot sell that night), restricted_ratio (share of available rooms Booking.com prices for a single night only), lead_in_rate / median_rate / highest_rate / rate_range, and refundable_premium_mediandemand_pressure — sold_out / high / building / normal, from fixed rules over those two ratios, always accompanied by demand_pressure_reason stating the counts behind the label ("2 of 5 room types unavailable"). Unlike the old urgency tier, every input is something the page stateslead_time_days, day_of_week, is_weekend on every room row — the booking window, which is the first thing any rate analysis segments on, and which previously had to be derived from two string columns in a spreadsheetrefundable_premium per room — cheapest refundable minus cheapest non-refundable rate: what the property charges for flexibility, comparable across the compset and directly actionablerate_spread per room — how widely a property fences its rate plans on one night🔴 Read this if you filter or alert on
rooms_left,availability_statusorstock_confidence. They were derived from the wrong field, and the values in datasets produced before this version are not room counts.
rooms_left was Booking's stay-length counter, not inventory. The extractor read b_nr_stays — which is the number of stay lengths Booking prices for that room (exactly len(b_stay_prices)), not rooms remaining. A live 3-day run made it unmistakable: a room priced for {1, 2} nights reported "2 rooms left", one priced for {1} night reported "1 room left" and was flagged low_availability_urgent, and rooms priced for {1…5} all reported "5 rooms left" — 11 of 11 rows matching the stay-price count exactly, never exceeding 5. So the Actor's entire scarcity signal was a length-of-stay number wearing an inventory label. rooms_left now comes only from Booking's visible scarcity badge ("Only 2 rooms left on our site!"), and is null when no badge is shownmax_nights_bookable — the same underlying number, published under its real meaning: the longest stay Booking.com prices for that room from that date. A 1 means only a one-night stay is quoted, which is a genuine length-of-stay restriction signal and the closest thing this Actor can offer to min_staylow_availability* rows. Most properties show no scarcity badge, so most rows now read rooms_left: null, stock_confidence: "hidden", availability_status: "available". That is the honest answer: unknown, not plentiful. The rows that still flag urgency are backed by a badge Booking actually rendered'balcon' is a prefix of 'balcony', and both sat in one flat keyword list, so an English "Balcony" produced ["balcony", "balcon"] — the same feature twice in the same row. Keywords now map to canonical names before deduplicationfacilities on 4 of 5 rooms in a live run. Interface labels are filtered outphoto_count reported 0 on every row. Images are blocked for speed, so a room photo count cannot be counted at all — 0 asserts "this room has no photos", which is never true. It is null now (the hotel-level photo count in the hotel_metadata dataset is unaffected)tax_clarity_label, primary_tax_label, rate_selection_reason, booking_terms_summary and max_nights_bookable are now present and explicitly null instead of being omitted, so CSV and Excel exports stop shifting columns between rowsA failing run used to cost more than the run: a red banner, a cryptic message, and no way for the person running it to tell whether the fault was theirs, ours, or Booking.com's. That is a reporting failure as much as a scraping one.
RUN_REPORT.json in every run's key-value store — verdict (complete / partial / failed / nothing_attempted), a one-line headline, a concrete what_to_do, totals split into proxy vs. page failures, and a per-hotel trail naming every date that failed and why. Written for every outcome, and written before the run can fail, so a red run still carries its own explanationwhat_to_do<title>, and the metadata extractor read it — so error rows and reports carried hotel_name: "This page isn't working" (or Booking's own "unable to handle this request" interstitial). A page that didn't load has no name; the URL slug is used insteadERR_PROXY_AUTH_UNSUPPORTED was not recognised as a proxy failure — found by driving a real browser at a socket that refuses CONNECT the way Apify does. Rejected proxy credentials were being filed as a page error and retried on the same dead IP. ERR_HTTP_RESPONSE_CODE_FAILURE is handled too, but only when a proxy is actually in the path, since a site can produce it on its ownTriggered by a real run: one Australian hotel, 7 dates, 7 error rows, all of them
Page.goto: net::ERR_TUNNEL_CONNECTION_FAILED, and a summary that blamed "proxy blocked/disabled, or a dead hotel URL". The browser had never reached Booking.com — and every retry re-dialled the same dead exit IP.
ERR_TUNNEL_CONNECTION_FAILED and friends are connection-level failures that cannot heal on the same IP; they were retried twice with exponential backoff (~30s per date, 3 identical failures). They are now recognised as proxy errors, handed straight back to the caller, and the date is retried on up to 2 genuinely new exit IPs before any error row is writtencreate_proxy_configuration() succeeding only proves Apify accepted the configuration — that gap is how a run logged "✅ Apify proxy ready" and then failed every single page. One HTTPS request through the tunnel now confirms it works and logs the exit IP, and the fallback ladder (requested group + country → requested group → DATACENTER + country → DATACENTER) degrades on verified failureuseApifyProxy boolean while the startup banner read the new proxyConfiguration widget — a user who picked their proxy in the standard Apify editor saw "Proxy: RESIDENTIAL" in the log and ran with no proxy at allerror_type field on error rows — proxy (the request never reached Booking.com; the URL and dates are not at fault) vs page (Booking.com answered but the page could not be scraped). The end-of-run failure message says which one dominated, and how many IP rotations were attemptedb_block_id, which assumes that key comes first in its JSON object — Booking's key order is arbitrary. On a verified page, 2 of 9 blocks carry b_block_id near the end of their object, so the window started after their own data and ran into the next block's: taxes_included came back null for those two, and the remaining options each carried the neighbouring rate's tax, occupancy and stay_prices. The enclosing object is now located by brace matching, so every field belongs to its own block. Verified against a saved page: all 9 rate options now satisfy tax = price / 11 (Booking's own "10 % TAX") and each option's 1-night stay_prices entry matches its own pricereview_count was truncated at the thousands separator. The page text reads 1,751 reviews and the regex could not cross the comma, so it captured 751. Every property with more than 999 reviews was understated. JSON-LD aggregateRating.reviewCount is now read first, and the text patterns accept ,, . and spaceshotel_address lost the street. All five DOM selectors are dead on current markup, so it fell through to a body-text regex and returned 6103 Perth, Australia. The street address is now read from the schema.org JSON-LD (85 Great Eastern Hwy Rivervale , 6103 Perth, Australia), with the Apollo formattedAddress as a second sourcehas_private_bathroom was false for rooms that have one. Booking's own wording in the room facilities is "Attached bathroom", which the pattern didn't know. "Shared bathroom" is a different string and still reads as falsestar_rating: 8. Star icons were counted with no upper bound and Booking nests two <svg> per star. The aria-label ("4 out of 5 stars") is now read first, and any count outside 1–5 is discarded rather than publishedfree_cancellation_until was null in 100% of runs — and was never listed as broken. It was parsed from policy wording in the visible text ("before October 6, 2026"), which doesn't match reliably in production sessions. It now reads b_cancellation_limit_until_epoch, a plain UNIX timestamp already sitting in the JSON parsed for taxes — no locale, no date-format guessingroom_view reported a sea view for rooms with a chair. The pattern /mer|sea|ocean/i had no word boundaries, so it matched the letters sea inside Booking's own label "Seating area" — any room with a seating area was labelled sea view. The same bug existed in three places (main detection plus two fallback tables); all now use \bsea\b-style boundariesproperty_type called every property a "Hotel". Booking's schema.org JSON-LD hardcodes "@type": "Hotel" for everything — a property literally named "Econo Lodge Rivervale" still came back as Hotel. The breadcrumb ("{Name} (Lodge) (Australia) Deals") carries the real category and is now tried first, with JSON-LD demoted to last resorthotel_neighborhood was always null. All four CSS selectors it relied on — including a hashed CSS-module class — are dead on current Booking markup (0 matches, verified). It now reads the structured "__typename":"Location" object embedded in the page, which is data rather than styling and survives redesignsprimary_tax_label and taxes_breakdown_detail were null at the top level even though the nested rate_options entries carried real values. _rate_option_to_dict() is an explicit whitelist used to build primary_rate_option / benchmark_rate_option, and the two new fields were never added to it — the exact "everything must come from the selected rate" failure this Actor is built to avoid. Both are now promoted, and documented in the dataset schemabooking_terms_summary overclaimed "Breakfast extra". is_breakfast_included: false only proves breakfast isn't bundled — not that it can be bought at all. It now says "Breakfast extra" only when the meal plan text carries an actual price (e.g. Good breakfast US$13), and the narrower, always-true "Breakfast not included" otherwiserate_selection_reason (why this rate was selected over the cheaper one on the page), tax_clarity_label (Taxes included / Additional taxes reported / Final cost not confirmed) and booking_terms_summary ("Free cancellation · Breakfast included · Pay later"). All three are rule-based and generated from the same code path that made the decision — never model-written, and an unknown condition is omitted rather than rendered as "No"hotel_latitude / hotel_longitude (full-precision coordinates), hotel_checkin_from (check-in start time; see Known issues) and hotel_sustainability_certified (Travel Sustainable badge)primary_tax_label (the main charge's label, e.g. 10 % TAX) on flat rows, and taxes_breakdown_detail (every labelled charge with its type and amount) inside each rate optionbenchmark_rate_option near the front and nightly_total_price in the middle. This view is the same complete field set in a deliberate reading ordermin_stay cannot be read from the property page at all (the only minimum-stay text there is an unfilled {num_nights} template belonging to the interactive date-picker), and hotel_checkin_from still returns null in production despite working on a fully-loaded page. Both are now in Known issues with the evidence, rather than sitting in a vague "fields under investigation" listtools/offline_extract.py — run the Actor's real extractors against a page saved from your browser: no proxy, no run, no cost. See Debugging extraction without spending a runtests/fixtures/, tests/test_extract_fixture.py) — a real saved Booking.com page, with 16 assertions pinning its exact prices, taxes, occupancies and hotel metadata⚠️ Behaviour change — read this if you filter on
is_refundable. It used to mean "any rate plan for this room is refundable". It now means "the rate you would actually book is refundable". Rows where only a non-primary rate was refundable flip fromtruetofalse. The same correction applies tomeal_plan,is_breakfast_included,book_now_pay_later,taxes_includedandtaxes_excluded. These fields are nownull(neverfalse/0) when no rate matched your occupancy —falsewould assert "not refundable",nullsays "unknown".
includeSoldOut: false returned zero room prices while reporting "Succeeded" — hotel_meta was initialized inside the if include_sold_out: block but read by every room push. With the flag off it was never bound, and the resulting NameError was swallowed by the per-day error handler, so every date of every hotel emitted an error record instead of rooms. It is now bound unconditionallyis_refundable, meal_plan, is_breakfast_included, book_now_pay_later, taxes_included and taxes_excluded were room-level rollups computed across all rate options (is_refundable was a logical OR; meal_plan was "the first plan that had one"). A single row could advertise "Refundable ✓ / Breakfast ✓" from one rate beside a price from another. All six now come from the same primary_rate_option.block_id as the pricehotel_name_clean was not cleaned — it was byte-identical to hotel_name, so it carried Booking's generated page title, e.g. Fashion Boutique Hotel (Hotel) (Morocco) deals. It now prefers the structured property name from schema.org JSON-LD or utag_data, falling back to a conservative suffix cleanup that strips only Booking's own qualifier vocabulary — a legitimate name like Hotel Example (Adults Only) is left untouched. hotel_name still carries the raw titlelow_availability_urgent keyed off whether Booking rendered a scarcity banner and never off the number itself, so 5 rooms left could rank more urgent than 4. Urgency is now monotonic in the count: 1–3 → low_availability_urgent, 4–5 → low_availability, 6+ → available. A hidden count stays available and is explained by stock_confidence; sold_out is still driven only by the explicit is_sold_out boolean, never inferred from a missing price or count!/non.?refundable/ && /free cancellation/), and a partially refundable rate matches neither pattern, so it silently fell through to false. New cancellation_policy field with three real states plus unknown, read from Booking's dedicated cancellation element (.e2e-cancellation) rather than the whole row. is_refundable is kept as a legacy boolean and is now true only for fully_refundable — a partial refund is not a free-cancellation guaranteeroom_capacity was null in almost every record — occupancy resolved through a JSON fallback into one variable, but the resolved value was never written back to the DOM-sourced variable that room_capacity actually reads. It now falls back to the largest capacity any rate option provesstock_confidence said hidden while rooms_left held a number — anything without a visible scarcity badge was labelled hidden ("no count exposed"), including rows that carried a count from the page JSON or room registry. Live output contained rows reading rooms_left: 3 beside stock_confidence: "hidden" in the same row of the default view. A badge-less count is now inferred; hidden means there is genuinely no countroom_capacity is now documented as a lower bound. When Booking.com doesn't expose physical occupancy directly it falls back to the largest capacity any rate option proves — and since rate options are filtered to your searched occupancy, that fallback can't exceed it. A "Quadruple Room" searched for 2 adults reports 2. The old schema text claimed "raw maximum physical occupancy, independent of any rate option", which is no longer accuratedocument.body.innerText was read unguarded while the identical read at the top of the same function already checked for a null body. When Page.goto times out the page never loads, document.body is null, and the throw lost score, stars, address and property type together, not just the review breakdown being parsed. This is why hotel_review_score could come back 9.4 on one run and null on the next for the same propertyv2.4.0 string while actor.json said 2.5.0, so a run log couldn't tell you which build produced it. It now reads actor.jsonproxyCountries changed from ["FR"] to ["US"] — it now matches the USD currency default. Booking.com shows a French visitor prices in EUR, so the old FR + USD pairing returned a converted figure, the very artifact the multi-country tip warns against. Runs that set proxyCountries explicitly are unaffectedproxyCountries accepts any country your Apify Residential proxy offers — including CN. It was documented as a fixed 15-country list, but the code always passed the entry straight through, so the restriction existed only in the docs. Adds 8 currencies led by CNY (also PLN, KRW, THB, TWD, CHF, MXN, ZAR)proxyCountries stays alongside it as the multi-market override, because the native widget takes exactly one country and comparing geo-pricing needs several. The old useApifyProxy boolean is still honoured, so existing saved tasks keep workingtests/, python3 -m pytest tests/) — 135 tests covering the fixes above and validating the dataset schema: every view column exists, is labeled, is actually emitted by the scraper, and every view link resolvescheck_out_date, total_stay_price, price_basis, plus proxy_country (so multi-market runs no longer look like duplicate rows at contradictory prices) and scrape_timestamp (so daily exports stack into a time series)nightly_base_price, taxes_and_fees_total and nightly_total_price together, all drawn from the same occupancy-matched rate. The legacy price_public / discount_percent are intentionally left out of that view: they come from the fixed 2-adult benchmark path, so a discount computed against nightly_total_price would be comparing two different rate options. Both fields remain under All fields, unchangedis_sold_out and availability_status together — the explicit boolean is a fact and stays; the four-tier status sits beside it, and stock_confidence makes a blank rooms_left read as hidden or capped rather than as missing data. Both appear in Rate shopping and Room comparison, so a sold-out row can never show as an unexplained blank priceoccupancy_match_status is visible in Room comparison — a blank Guests cell now has an on-screen explanation (no_compatible_rate means no rate proved capacity for your party, so max_guests is null by design)primary_rate_option, benchmark_rate_option and rate_options are fully documented in the dataset schema — every property and its nullability, including the fact that rate_options entries use a different raw shape (extra original_price / taxes_and_fees / stay_prices, no is_breakfast_included). An AI-facing view should not expose an undocumented generic objectprimary_rate_option (and therefore max_guests) was silently benchmarked against a hardcoded 2-adult standard regardless of what you actually searched for. It's now selected against your real adults/children/rooms input, with the minimum required capacity split correctly across multiple rooms (4 guests across 2 rooms now correctly requires 2 guests/room capacity, not 4)required_guests_per_room and occupancy_match_status (capacity_compatible, uncertain_children, or no_compatible_rate) — so you can see exactly how confident the occupancy match is, including an honest flag when children are in the party (child ages aren't collected, so capacity can't be fully verified for those bookings)primary_rate_option is null — never a guessed fallback — when no rate option can prove enough capacity for the request, instead of silently falling back to a 2-guest assumptionbenchmark_rate_option — the old fixed 2-adult rate is preserved here for revenue-benchmarking use cases. The legacy price_primary / price_public fields keep their original meaning unchangedhas_private_bathroom — was only matching "private bath...", so the very common "Ensuite bathroom" facility label was silently returning falsemax_guests — now reflects the primary rate option actually matched to your requested occupancy, not the room's raw physical capacity. New room_capacity field carries the raw capacity separatelyprimary_rate_option — a deterministic object where every field (price, refundability, cancellation deadline, meal plan, taxes) comes from the same rate option, never mixed across different ratesnightly_base_price, nightly_total_price, total_stay_price, taxes_and_fees_total, price_basis. Legacy price / price_primary / price_public kept for backward compatibilitynull for all price fields — never 0requested_adults, requested_children, requested_rooms, number_of_nightshotel_address and property_type on every room rowhotel_metadata alias) — the default room-price dataset no longer contains blank/"undefined" discovery rows. Hotel score, stars, and neighborhood remain denormalized onto every room rowfacilities array from the default view (still available under "All fields"), kept room_size_sqm and room_amenities to avoid duplicating the same information twiceconcurrency, 1–5) — each hotel scraped on its own proxy sessionproxyCountries field scrapes from multiple source markets in one run; each result tagged with proxy_country for geo-pricing comparisonincludeWholesaleRates flag captures partner/bbasic rates, tagged separately as is_wholesaleroomId is now the single source of truth for deduplicationstay_prices (length-of-stay pricing matrix)taxes_included / taxes_excluded breakdownbook_now_pay_later flagstock_confidence — distinguishes exact / capped / hidden signalsprice_public, room_size_sqm, room_view, has_private_bathroom, room_amenitiesrooms_left + availability_status availability tracking