Booking.com Hotel Scraper – Prices, Room Rates & Reviews
Pricing
from $2.54 / 1,000 search results
Scrape Booking.com hotel prices, room rates and availability via the mobile API. Full per-room rate table with itemised taxes and fees, family pricing by child age, guest reviews and property details — one actor, not four. Search by destination, GPS radius or hotel id. No API key needed.
Pick Search for the normal flow, or an enrichment mode to re-check properties you already have ids for without searching again. Watch rates is the one keyed on individual rates rather than whole properties, for price and availability monitoring.
Check-in date. Pick a day, or switch the picker to a relative value like "30 days" — relative is the one to use in a saved task or a schedule, since a fixed date eventually falls into the past and Booking only quotes future stays. Empty = 30 days from today.
Used by more than one mode: a Search prices this stay, Room pricing & availability re-prices it, and Guest reviews uses it only when no ufi is given.
Departure date, absolute or relative the same way as check-in. Defaults to check-in + 1 night.
Ask "any stay starting in the next N days" instead of one fixed stay. Set this together with Nights per stay below.
The window starts today, or at Check-in if you set one. Each day in it is a separate search of its own, billed separately — a 30-day window costs roughly 30× a single-date run — so keep it as short as the question allows and set Max accommodations, which is a budget across the whole sweep, not per day.
Capped at 60 days. Only applies to the Search and Room pricing & availability modes: the others return the same answer whatever the dates.
How long each stay in the window is. 1 asks for single nights — "the cheapest single night in the next 30 days". Ignored unless Search a window of days is set.
Ages of the children in the party, one per line (e.g. 5 then 9). Booking prices family stays by child age (free cots, kids-stay-free rules), so set this for correct prices and to surface family rooms.
Currency for displayed prices.
Property's own currency is the first choice and matches Booking's own picker: prices come back in whatever the property quotes in — MYR in Kuala Lumpur, THB in Bangkok — with no conversion. Every row states its own currency, so you always know which you got.
Booking cannot be asked for that, though: left to the property, the room-list request comes back with no rooms at all — on every property, not a few (measured 2026-10-29 on five properties in four markets). So this Actor reads each property's own code first and then asks for it explicitly, which is what the setting promises. Where a property's code cannot be read, its rates are skipped rather than mispriced and the run says so in its log, naming this input — pick an explicit code for that one.
Otherwise pick one of 147 currencies. That is every ISO-4217 code Booking honours on this surface, established by requesting a property once per code and reading back the currency it priced in, with bogus codes as the control.
The nine it refuses are ERN, FKP, GIP, KPW, SHP, SLE, TMT, VED and ZWG. They are refused outright rather than falling back silently, so you cannot ask for one by accident.
Booking's app only offers 49 of the 147 in its own menu, and its exchange-rate table lists 188 — including pre-euro currencies and gold. The 147 here is the set measured to actually price a room.
Every price in a row follows this setting, including the cancellation ladder and the prepayment schedule. One documented exception: details.damageDeposit.amount stays in the property's own currency, because a deposit is collected at the desk in local money — its currency says so.
Locale for localized text (names, facilities, reviews).
Pick how to find properties, or leave on Auto. Ignored unless this run is a Search.
Place name (city, region, landmark) resolved via Booking's own autocomplete — the easiest way to start, e.g. "Amsterdam".
Autocomplete matches what Booking has a destination for, which is not always what you would guess: "Queens" resolves to Queenstown in New Zealand, and "Manhattan", "Newark" and "Long Island City" resolve to nothing at all. The run logs what it resolved to — check it. For a metro area Booking has no destination for, use mode 5 (custom area) instead.
Naming one specific hotel here also works: it is detected and fetched directly, the same as mode 2.
Scrape specific properties by numeric Booking ID, one per line, e.g. 10004. Set this and every other sub-mode is ignored. These ids are also what the enrichment modes work on, so the same list re-checks rooms, reviews, scores or nearby places without searching.
This must be the internal numeric id, not a URL slug or a property name. To find it, open the hotel's Booking.com page, view the page source and search for hotelId.
Unlike a search, this always returns a row per id — including one saying why there is no price (sold out, minimum stay, closed, unknown id).
Exact numeric destination id (ufi), e.g. -2140479 for Amsterdam. This field takes a number: typing "Amsterdam" here is rejected — use mode 1 for a name.
Only useful if you already have the id from a previous run's output.
Exact numeric region id. This field takes a number, not a region name — use mode 1 for a name. Only useful if you already have the id.
Sub-mode Point and radius: search outward from one GPS point, nearest first — "within N km of this venue" rather than "in this city". Latitude and Longitude are required together; Radius is optional.
Only keep properties within this many kilometres of the point. Applied after the results come back, not by Booking — so a tight radius spends your Max accommodations budget on properties that are then discarded. Leave empty for nearest-first with no cut-off.
Sub-mode Bounding box: sweep an arbitrary rectangle instead of a destination. Use it for ground Booking has no single destination for — New York's city destination holds ~520 properties, while a box over the same area also reaches Jersey City, Hoboken and North Bergen.
All four corners are required together. A box costs far more requests per property than a destination search, so keep it tight and set Max accommodations.
Coverage reporting differs. A destination search can say how complete it was ("5,822 of 5,844 properties, 99.6%") because Booking reports a total; a box cannot, so the log reports whether every cell was fully reached instead of a percentage.
Booking's search stops returning new properties at roughly 1,000 per destination. With this on, the actor splits a large destination into geographic shards and merges the results, reaching several times more properties (measured: 1,104 -> 6,170 for Tokyo). Costs proportionally more requests, and each property is still returned - and billed - only once. Left unset, it turns on automatically when Maximum results is above 1,000.
Limit results to these property types. Leave empty for all types. Pick from the list here; via the API this field takes Booking’s numeric type ids as strings (e.g. "201" for Apartments). An id sent as a number, or a type name, is rejected before the run starts. To pass names case-insensitively ("Apartments", "villa"), or ids as numbers, use the snake_case spelling "accommodation_types" instead. See the README for the full id → name table.
[]Only return properties with at least this guest review score (1–10). Applied client-side.
Only return properties at or above this total stay price, in the selected currency. Applied client-side.
This runs on the price set by Price basis: by default Booking's displayed price, which is net of taxes and fees that are charged on top. On a property with excluded charges the all-in cost is higher, so a budget set here can be overshot — set Price basis to all-in to filter on what the guest actually pays.
Only return properties at or below this total stay price, in the selected currency. Applied client-side.
This runs on the price set by Price basis: by default Booking's displayed price, which is net of taxes and fees that are charged on top. On a property with excluded charges the all-in cost is higher, so a budget set here can be overshot — set Price basis to all-in to filter on what the guest actually pays.
Which price Minimum price, Maximum price and Cheapest first are measured against.
Booking's displayed price (the default) is the figure Booking shows in its own result list. It is net of any tax or fee charged on top — city tax, VAT, a resort fee — so the stay can cost more than the number you filtered on. Pick this to match what you see on the website.
All-in price is the displayed price plus every charge Booking reports as excluded, i.e. what the guest pays. Pick this when a budget or a "cheapest" ranking has to be true of the final bill. Each row carries both figures either way, as price.total and price.total_with_charges.
How Booking orders the results. Cheapest first is the default. These are Booking's own seven orderings - the same menu its app shows - and the order is applied by Booking itself, so a small Max items still gives you the real cheapest (or best-reviewed) properties for the whole destination rather than the cheapest of the first page.
Entire homes & apartments first promotes apartments and aparthotels above hotels, which is Booking's own "upsort" ordering rather than a filter - hotels still appear, lower down. Use the property-type filter if you want only homes.
Most expensive first was withdrawn on 2026-10-21. Booking has no such ordering on this surface, so it had to be ranked here over an over-fetched candidate set, which made it silently approximate whenever the over-fetch did not reach far enough. Asking for it now fails with a message instead. Sort the dataset yourself after the run - every row carries its own price.
Cheapest first orders by the price set by Price basis. With the default (Booking's displayed price) the order is Booking's own; with all-in the ranking is done here, over an over-fetched candidate set, because Booking has no all-in sorter.
Mostly ignored — the direction is part of Sort results by now. Pick "Cheapest first", "Most stars first" and so on. This field is kept so existing saved tasks and schedules keep validating.
"Descending" is refused, not ignored, on every order Booking only provides one way — cheapest, most/fewest stars, nearest, homes-first. The run stops with a message naming the alternative instead of quietly serving a different order under your label. Only Best reviewed genuinely has both directions.
To get the reverse of an order Booking does not offer, sort the dataset after the run: every row carries its own price, review score and star rating.
Add both room sections: the per-rate products list (board, cancellation, deals, price) AND the distinct room-type rooms list (name, occupancy, availability, lowest price). Costs one extra request per property in search mode.
When rooms are included, keep only rates Booking would actually sell to your party (its is_block_fit flag) in products, and compute rooms[].minPrice / productCount from those. Turn off to get every rate of every occupancy (each still carries fitsParty).
Add a details object per property: name, type, star rating, review score/count, location, main photos, named facilities, languages spoken and address. Costs one extra request per property in search mode.
Add nearby landmarks, public transport, dining and airports with distances, under "details.surroundings". Costs one extra API request per property and is billed as its own "Nearby places" event. Off by default: until 1.0.50 this was fetched automatically with "Include details" and not charged.
Add a reviews array per property (author, score, title, pros/cons, date). Costs one request per 10 reviews per property.
How many reviews to fetch per property (only when "Include reviews" is on). Capped by the property's total review count.
Add per-category review subscores (staff, cleanliness, location, value, comfort, facilities, wifi) and the aggregated review summary, under "reviewSubscores" and "reviewSummary". Costs one extra API request per property regardless of how many reviews you fetch, and is billed as its own "Review scores" event. Off by default: until 1.0.50 this rode along free with "Include reviews".
Add the extra_charges price breakdown (taxes/fees) to each result and product.
The properties to run Room pricing & availability on, one numeric Booking ID per line, e.g. 10004. This must be the internal numeric id, not a URL slug or a property name: open the hotel's Booking.com page, view source and search for hotelId.
Keep only rates Booking would actually sell to the party in Stay details below. Turn off for every rate of every occupancy. This is the Rooms-mode copy; it overrides the shared Only rates that fit the party field.
Break each tax and fee out of the rate instead of a blended total. This is the Rooms-mode copy; it overrides the shared Include extra-charge breakdown field.
The individual rates to re-check, one product ID per line, e.g. 25768602_431556758_2_0_0. These are the products[].id values from an earlier Search or Room pricing & availability run.
The property is worked out from the ID, so nothing else has to identify it — but a rate exists only for a given stay and party, so Stay details still applies and should match the run the IDs came from. One row comes back per ID you ask for, including rates that are no longer on sale.
The properties to run Guest reviews on, one numeric Booking ID per line, e.g. 10004. This must be the internal numeric id, not a URL slug or a property name: open the hotel's Booking.com page, view source and search for hotelId.
Booking's reviews endpoint refuses to return anything without the destination's ufi, so the reviews mode needs one. Take it from an earlier search run's output and paste it here to skip a lookup; leave it empty and one extra request per property derives it. A ufi identifies a destination, not a property, so one value covers every property in that destination.
ISO 2-letter code for the property's country, paired with the ufi above. Optional — Booking tolerates it being empty.
Capped by the property's own review count. This is the Reviews-mode copy; it overrides the shared Max reviews per property field.
The properties to run Review score summary on, one numeric Booking ID per line, e.g. 10004. This must be the internal numeric id, not a URL slug or a property name: open the hotel's Booking.com page, view source and search for hotelId.
The properties to run Nearby places on, one numeric Booking ID per line, e.g. 10004. This must be the internal numeric id, not a URL slug or a property name: open the hotel's Booking.com page, view source and search for hotelId.
The properties to run Static property details on, one numeric Booking ID per line, e.g. 10004. This must be the internal numeric id, not a URL slug or a property name: open the hotel's Booking.com page, view source and search for hotelId.
Leave empty for the full record. Selecting Nearby places without Static details keeps a details object holding only surroundings.
[]Maximum number of accommodations to return.
Above 1,000 this turns Deep search on by itself, because Booking's search stops returning new properties at roughly that point.
This limit is the usual reason a run returns less than the destination holds. Every run writes a RUN_SUMMARY record to its key-value store saying how many properties were available, how many were delivered, and which limit stopped it — so you can tell a complete result from a truncated one without guessing. The run's status message says the same thing in words when a run was cut short.
Maximum parallel requests for product/detail fetches.
Unit system for distances - distance from the city centre and the nearby landmarks, transport and airports returned with includeDetails. Booking localises distances by language (metres for German, feet for US English); this normalises them to the system you pick.
Also write an Excel workbook to this run's storage, with a sheet per section (Properties, and Rates/Rooms/Reviews when those are included) instead of nested JSON in a cell. Download it from the run's Storage tab. Does not change the dataset or what you are charged.
In enrichment modes only that mode's sheet fills: Rates and Rooms for Room pricing, Reviews for Guest reviews. The Properties sheet holds the id alone, and nearby places, review scores and static details have no sheet — they reach you through the dataset instead.
Name for the workbook in the key-value store.
Also write a KML file with one placemark per property, ready to open in Google Earth, Google My Maps or QGIS. Each pin carries the price, review score, address and a link to the property, plus a photo when Include details is also on. Properties without coordinates are skipped.
Only produces pins in Search mode. The enrichment modes return rows without coordinates, so a map built from them has 0 placemarks. For a map of properties you already have ids for, use Search with the Specific properties sub-mode.
Name for the KML file in the key-value store.
Shade the placemarks so the map reads at a glance. Price uses this run's own quartiles (cheapest green, dearest red); review score uses fixed bands (9+ green, 8-9 amber, 7-8 orange, below 7 red).
Proxy settings. Apify Proxy recommended.
{ "useApifyProxy": true}Where to look, as free text — a city (Amsterdam), a landmark, or a product name. Booking resolves it server-side. Give this, or Destination ufi, or a latitude/longitude pair.
Booking's own numeric destination id — the same ufi the property search uses, e.g. -2140479 for Amsterdam. More precise than free text when you already have it.
Search around a point instead of a destination. Needs Longitude too.
Only with a latitude/longitude pair. Caps how far from the point results may be.
Sorted server-side by Booking. Leave on the default unless you need a specific order — an unrecognised value is ignored upstream rather than refused.
Keep only attractions rated at or above this many stars. Booking rates attractions out of 5, not out of 10 like hotels — so "4.5" here is strict, and a 1-10 score such as 8 matches nothing.
Pick one or more of Booking's own product categories. Filtered by Booking, not client-side. These seven are the whole taxonomy — the same set and the same ids came back for Amsterdam, Rome and London, so they are global rather than per-destination. Leave empty for everything.
Booking exposes exactly one label filter on this surface today. Kept as a list because the upstream field takes several.
How many products to ask for per request while paging. Does not change the total — that is Max accommodations.
The attractions to look up, one id per line, e.g. PRz8B1W8aYsI. Used by Attraction details and Attraction availability. You get these ids from a run in mode Attractions (the attractionId field).
First date of the availability window. Used by Attraction availability, and also narrows Attractions to products bookable in the window. Accepts a relative value like "2 weeks".
Last date of the availability window, absolute or relative. Booking returns no product at all for one with nothing bookable inside the window — the run reports that as bookableInWindow: false rather than dropping it.
Off by default. Adds the bookable timeslots for each available date — start time, ticket type, tickets left and price. Booking serves timeslots one date per request, so this costs one extra request per available date; Timeslot days caps how many.