Booking.com Hotels - Search, Prices & Reviews

Two ways to use it, and you pick by what you give it.

Search a destination and get every property back as a structured row: name, address with coordinates, star rating, guest review score and count, room type, cancellation policy, and the total price for the stay you asked about.

Look up hotels one by one by pasting their page addresses, and get the review score broken down by category, the full postal address and the landmarks nearby. None of that appears in a search result.

Either way: your dates, your currency. No API key, no login.

The prices are the ones a browser shows

Worth stating plainly, because a scraper quietly returning a different rate than the site shows is the failure that costs you money.

The same Amsterdam search was run twice, once through this Actor and once in a real Chrome window, and the results compared property by property. Of the 19 properties both runs saw:

field	agreement
total price	19 of 19 identical
review score	19 of 19
review count	19 of 19
star rating	19 of 19
free cancellation	19 of 19
room type	19 of 19

Not close. Identical, to the cent.

What you get per property

Identity and place — name, url, property_id, address, city, country_code, latitude and longitude, plus district, distance_from_centre, public_transport and is_centrally_located as Booking states them.

Reputation — review_score out of 10, review_count, review_word ("Excellent"), and star_rating.

A note on those two, because they are not the same kind of number. review_score is built from guest reviews. star_rating is supplied by the property, and Booking says so itself: it may be self-assigned rather than awarded by any authority. Sorting a list by stars is sorting by what hotels claim about themselves.

The room — room_type, room_size_sqm where published, beds, bedrooms, bathrooms.

The booking terms — free_cancellation, no_prepayment, price_includes (whether taxes and fees are in the number) and deal_badges.

The stay — checkin, checkout and nights on every single row, because a price without its dates is not a price.

Two prices, two currencies, and no guessing between them

Booking publishes every price twice: once in the currency your search asked for, and once in the property's own. On one Amsterdam result those read US$559.93 and €481.39 for the same two nights, a 16% gap that is entirely exchange rate and rounding.

Picking whichever came first would build a table that silently mixes currencies across rows. So both are returned, each with its code:

• price_total and price_currency — what you asked for
• price_total_hotel_currency and hotel_currency — the property's own
• price_per_night — price_total divided by nights

Ask for EUR on a European hotel and the second pair is empty, because there is nothing to convert. Ask for EUR on a Tokyo hotel and you get €239.58 alongside ¥43,000.

The Search from country input is recorded on every run for the same reason. Travel prices are regional, and a run that does not pin where it searched from cannot be compared with the run before it.

How many properties you get, and why paging is not the answer

Booking's paging does not work for this. Asking for later pages returns the same properties again: offsets 25, 50 and 75 each returned 22 to 23 of the same 26 hotels, and four pages together yielded 34 distinct properties rather than 104.

Sort order does work. The same search under different orderings surfaces different slices of the inventory, because each ordering shows a different top of the list. Measured on one Amsterdam search:

sort orders used	distinct properties
one	26
three	73
four	92
five	106

So Sort orders to collect is the real control over coverage. Each order you add is one more request and roughly 25 more hotels. Every row records found_by_sort, so you can see which ordering surfaced it, and the cheapest hotels genuinely do arrive under the price ordering rather than the default.

Detail mode: the review score broken apart

Paste hotel page addresses into Hotel page addresses and each one is fetched directly. That page carries things a search row cannot:

The category scores. Booking scores seven things separately, and a search result gives you none of them:

	Zoku Amsterdam	The Savoy	Park Hyatt Tokyo
Overall	8.9	9.4	9.3
Staff	9.3	9.7	9.4
Cleanliness	9.1	9.7	9.8
Location	8.9	9.7	9.2
Value for money	8.2	8.5	8.6
Free wifi	9.4	9.8	9.5

The spread is the story. All three score worst on value and best on staff or cleanliness, which is a different fact about each hotel than its headline number, and it is the one that decides between two properties rated the same.

The full postal address, split into street, region, postcode and country, which is what makes these rows joinable against anything else you hold.

Nearby landmarks, the room names offered for your dates, the earliest check-in time, and Booking's own description.

Two honest notes on that data. address_area is not the city: Booking files The Savoy under "Strand" and Zoku under "Weesperstraat 105", so the field is named for what it contains rather than what you might hope. And Booking scores out of 10, not 5; review_score_scale says so on every row so nothing has to be assumed.

Every detail row also carries subscores_agree_with_overall, a cross-check that the category block really belongs to that property.

Filters

• Hotel page addresses — paste these for detail mode; leave empty to search
• Destination — city, region, district or landmark, in Booking's own words
• Check-in / Check-out — a search without dates has no prices at all, so a date is always used; leaving them empty gives a two-night stay 30 days out
• Adults, Children, Rooms — these change availability, not just the total
• Currency — the code the headline price is shown in
• Maximum properties — the ceiling on both time and cost

Run summary

The search you ran, properties returned, how many carried a price and a review score, which currencies appeared, and requestsRetried.

That last number is worth watching on a schedule. Occasionally a search comes back without its results and is simply requested again; that is normal and is handled inside the run. A retry count that climbs run after run is the early warning that something changed, and it is far more useful than an empty dataset with no explanation.

What people use this for

Rate monitoring. Run the same destination and dates daily and keep the rows. Because the stay dates are on every row and the currency is explicit, the series is comparable without any cleanup.

Competitor pricing. For a hotel operator, the same search a guest would run, with every rival's total for the same two nights beside your own.

Market research. Coordinates, star rating, review score and price in one table is enough to map what a city charges by district and by segment.

Travel aggregation. One search, one table, one shape, with the currency question already settled.

Notes

Prices and availability are live and change through the day. A run is a snapshot, which is exactly why the dates, the currency and the country searched from are all recorded alongside the numbers.

A destination that matches nothing, or a stay with no nights in it, is reported as exactly that rather than as an empty result you would have to interpret.