Livescraper
Sign inGet Started
Booking Prices Scraper

Every room type,
in its own columns.

Paste Booking.com hotel URLs, one per line, and each hotel comes back as a single wide row - the property details first, then room_1_*, room_2_* and so on, each carrying that room's type, prices, occupancy options, facilities and booking conditions. Check-in and check-out dates are added for you.

Start free See pricing
one-time 500 free rows$0.002 per row afterone row per hotelCSV · JSON · Excel
How it works

One field,
and nothing to configure.

There is no limit box and no sort menu on this form. The list of hotels is the whole input.

  1. STEP 1Sign in to the platform.
  2. STEP 2Open the Booking Prices Scraper.
  3. STEP 3Paste one booking.com/hotel/<cc>/<slug>.html URL per line - or upload a CSV, XLSX, TXT or Parquet file.
  4. STEP 4Set a residential PROXY_URL before you run it. In the service's own words, Booking blocks free and datacenter IPs, so one is needed for prices - and your real IP is never used.
  5. STEP 5Click Get Data and download as CSV, JSON or Excel.

The form accepts a bare hotel slug as well as a full URL. In our own runs the bare slug resolved under a different country path and came back without hotel data, so the full URL - the one that carries the country code - is what we would paste.

Why teams use it

A rate table
you can actually diff.

One row per hotel, as wide as it needs to be

Most price scrapers give you a row per rate, which means the hotel's own details repeat on every line and you spend the first hour pivoting. Here the property sits once at the left and the room types fan out sideways as room_1_* through room_N_*. Two runs of the same hotel line up column for column, which is what makes a diff possible at all.

The stay window comes back with the price

A rate means nothing without the nights it was quoted for. checkin and checkout are added automatically and travel in the row, so a file you exported last month still says which stay it was pricing. In every row we hold the two were consecutive days - a single night - and both were filled.

The conditions, not just the number

room_N_prices is a list rather than a single figure, and it sits beside room_N_choices and room_N_options - the booking conditions and the occupancy each rate was offered at. A cheaper number that is prepaid, non-refundable and for one guest is not the same product as the flexible one above it, and this export keeps the difference visible.

Data dictionary

Sixteen fixed columns,
then five per room type.

The names and their order come from the service's own column code, so they are dependable. What the values look like was measured on a much narrower sample - the note at the end says exactly how narrow, and which fields did not survive it.

query
What you submitted for this row - a hotel URL or a bare slug - echoed back. The scraper writes it, so it is there even when nothing else is.
id
Booking's own identifier for the property. Stable across our runs of the same hotel, which makes it the key to join on rather than the name.
name
The property name.
description
The property blurb. In our rows it arrived truncated with a trailing ellipsis rather than in full.
reviews
The property's review count, as a string rather than a number. It moved between our runs, which is what you would expect of a live figure.
rating
The property's guest score, again as a string - 8.0 in our rows, on Booking's ten-point scale.
stars
The star classification. Treat this one with suspicion. Across seven populated rows of the same hotel we saw 3, 5, 2, 4 and twice nothing at all, so on our evidence it is not a reliable property attribute.
city
The city. Uppercase in our rows, and empty on two of the seven.
country
The two-letter country code - and worth reading, because it tells you which national path the URL resolved under.
address
The street address as one string.
latitude
Decimal latitude, as a string. Filled on five of our seven populated rows.
longitude
Decimal longitude, same shape and the same gaps.
detailed_rating
The sub-scores as a JSON object - in our rows Staff, Facilities, Cleanliness, Comfort, Value for money, Location and Free Wifi. Parse it; do not read it as a number.
checkin
The check-in date the prices were quoted for, ISO format. Added automatically.
checkout
The check-out date, same format. In every row we hold it was the day after checkin.
gallery
A JSON array of image URLs at mixed sizes.
room_N_type
The room type's name - Economy Twin Room, Deluxe Suite and so on. N counts up from 1, and the widest row we saw carried seven.
room_N_prices
A JSON array of price objects, each with currency, value and display. More than one, because a room type is usually offered on several rate plans. No currency is promised - ours varied between runs, so read the field rather than assuming.
room_N_options
The occupancy each rate was offered at, as a JSON array - in our rows phrased like Max. people: 2.
room_N_facilities
A JSON array of the room's features. The first entry is usually the size, and the unit is not fixed: our runs returned both square feet and square metres for the same room.
room_N_choices
The booking conditions attached to the rates, as a JSON array - prepay, modification and breakfast terms in our rows. This is the column that tells you whether a low number is actually comparable.
postal_code
The postal code.
price_range
Intended to carry a price band for the property.
url
The Booking page the row was read from. Compare it against query - if you submitted a bare slug, this is where it actually went.

Where these come from, and how far they stretch. The column names and their order are read straight from the service's own column code, so the shape of the file is not in question: sixteen hotel columns, then a block of five for each room type found, then postal_code, price_range and url. One caveat on order - the on-screen table and the Excel file put those last three at the end, while the JSON we hold places them between gallery and room_1_type. The described VALUES are on much narrower ground. We hold thirteen run exports, but six of them are an older, discontinued shape that no longer matches this service and are ignored here entirely. The seven current ones contain ten hotel rows, and every row is the same hotel - the form's own example property. So every observation above is a fact about ten rows of one hotel across seven runs, which is why the ones that failed are named as loudly as the ones that worked: price_range was empty on all ten, stars disagreed with itself run to run, latitude, longitude and city were missing on some rows, and in one run every room's prices came back empty while the rest of the room columns were filled. Set a residential PROXY_URL first - the service says plainly that Booking blocks free and datacenter IPs and that one is needed for prices - then run the free tier against a hotel you care about and read your own first row.

Run one hotel free
Common workflows

Three jobs people
run this for.

All of them start from a hotel link you can copy out of the address bar.

Revenue

Watch a compset without opening twelve tabs

Put your competitors' hotel URLs in the box and every property becomes one row with all its room types priced side by side. Run it again tomorrow and the two files diff column for column, which is the whole reason the layout is wide rather than long.

Revenue management
Positioning

See which room type actually undercuts you

"They are cheaper" is rarely true of a whole hotel. It is usually one room type on one rate plan. With room_N_type, room_N_prices and room_N_choices in the same row you can see whether the low number is a comparable product or a prepaid, non-refundable single.

Commercial · Strategy
Travel

Build a rate file for a client shortlist

Agencies and corporate travel teams price the same handful of properties over and over. One paste gives you the property details, the geo fields, the room inventory and the conditions in a single file, with the stay window written into every row so last month's export still explains itself.

Travel · Procurement
Get started
Pricing

Pay per hotel row,
however many rooms it has.

No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.

Free tier

500 free rows - $0

For every new account, one time. No credit card. All scrapers unlocked. A row here is a whole hotel with all of its room types, so the free tier stretches a long way on this particular service - long enough to price a full compset before you have spent anything.

$0 forever
Pay-as-you-go

$0.002 per row, after the free tier

The same flat rate as every other scraper on the platform, and the unit is the hotel rather than the rate. A property with seven room types on three rate plans each is still one row. That makes repeat runs - which is what price monitoring is - unusually cheap here.

Most popular
Enterprise

Custom - a compset, on a schedule

Volume pricing, SLAs, dedicated workers and tailored onboarding for teams repricing a market rather than a shortlist. Tell us your numbers and we will quote.

Talk to us
Start free See full pricing
10% off your first paid run.Use code LIVESCRAPER10 at checkout.
Sign up
Pairs well with

The same property,
from another side.

A rate is one fact about a hotel. These return the others.

Hotels Search Scraper

Properties from a destination search rather than a list you already have. Run it first when you need the shortlist itself, then bring the URLs here for the rates.

Explore

Hotels Reviews Scraper

What guests said, rather than what the room costs. A rate gap that looks unjustified usually explains itself in the reviews of whichever property is cheaper.

Explore

Tripadvisor Search Scraper

The same properties as a different marketplace ranks them. Useful for checking whether the hotel you are pricing is the one travellers actually see first.

Explore
The legal bit

Is it legal to scrape
Booking.com prices?

Short answer: yes, when you only collect what is publicly visible on a hotel page - and that is all this service reads.

A hotel's page, its room list and its advertised rates are public. Anyone can open the listing without an account and read them, and collecting publicly visible pricing for market research and competitive analysis is long-settled practice. As long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it.

This export is unusually free of personal data - it describes rooms and rates, not people. That makes the GDPR question narrow rather than absent: the geo fields and the property address are business information, and nothing here identifies a guest. What does deserve care is what you do with prices. Watching a competitor's public rates is normal commercial practice; agreeing with them about what those rates should be is not, and no scraper makes that legal.

Booking's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, read only what an ordinary visitor sees, run no third-party trackers on the data layer, and your exports self-delete after 30 days.

Sign up now
livescraper.app · principles
Public hotel pages only✓
No logins, no paywalls✓
Rates are commercial data - watch them, do not coordinate on them!
GDPR-aligned by default✓
Exports self-delete (30 days)✓
The same rooms and rates any traveller sees on the listing.
Common questions

Things people ask before signing up.

The questions we hear most. Something else? Talk to us - humans write the answers, not bots.

What does one row represent?+
One hotel, not one rate. The property details sit at the left of the row and every room type fans out to the right as room_1_type, room_1_prices, room_1_options, room_1_facilities, room_1_choices, then room_2_* and so on. The file is therefore as wide as the largest hotel in your result set, and the widest row we have seen carried seven room types.
What columns will the export contain?+
Sixteen fixed hotel columns - query, id, name, description, reviews, rating, stars, city, country, address, latitude, longitude, detailed_rating, checkin, checkout, gallery - then five columns for each room type, then postal_code, price_range and url. That order is read from the service's own column code. One wrinkle worth knowing: the table and the Excel download put those last three at the end, while the JSON puts them before the room blocks.
Do I need a residential proxy?+
Yes, and the service says so itself: Booking blocks free and datacenter IPs, so a residential PROXY_URL is needed for prices, and your real IP is never used. If you run without one, the platform's own message is that Booking gates the availability and price API for those addresses. Set it before your first run rather than after an empty one.
Can I set check-in and check-out dates?+
Not on this form. The dates are added automatically, and they come back in the checkin and checkout columns so every row records the stay it was priced for. In all of the rows we hold the two dates were consecutive days, so the quote was for a single night.
Is there a limit or a sort option?+
No. Unlike most of our scrapers this form has neither - the list of hotel URLs is the entire input. You control the size of the run by how many hotels you paste.
Does a bare hotel slug work instead of the full URL?+
The form says it does, and we would still paste the full URL. When we submitted a bare slug, the row came back with the url rewritten under a different country path, the country column reading us, the name showing Booking's generic page title and every other field empty - no room columns at all. The full URL carries the country code, and those runs returned the complete row.
Which columns should I not trust?+
Two. price_range was empty on every row we hold, so we have never seen it carry a value. And stars disagreed with itself: across seven populated rows of the same property we saw 3, 5, 2, 4 and twice nothing at all, so on our evidence it is not a reliable classification. Check both on your own first export.
What currency are the prices in?+
We do not promise one. Each entry in room_N_prices is an object carrying its own currency, value and display fields, and the currency was not the same across our runs - read it from the row rather than assuming. The same caution applies to room sizes inside room_N_facilities, which arrived in square feet in some runs and square metres in others.
Have you actually run this?+
Yes, and the honest scope is narrow. We hold thirteen run exports, but six are an older shape that no longer matches this service and we ignore them. The seven current ones contain ten hotel rows, and every one of them is the same property - the form's own example hotel. So the column names and the layout are solid, and everything we say about values is a fact about ten rows of one hotel.
What does it cost?+
The first 500 rows on a new account are free and one-time; after that it is $0.002 per row - about $2 per 1,000 - pay-as-you-go with no subscription. A row is a whole hotel with all of its room types, which makes repeat price checks cheap. Credits do not expire and there is no monthly reset.

Price a compset
in one paste.

Set a residential proxy, paste your competitors' hotel URLs, and get every room type priced in one row each. Your first 500 rows are free.

Start free See full pricing
Activates instantly · no card required

Export Booking.com room rates as rows

Hotel pricing is awkward to collect because the interesting unit is not the hotel and it is not the rate - it is the pair. A property is cheap or expensive only relative to a room type, a stay window and a set of booking conditions, and a page that shows you all of that at once is a page you cannot easily compare against yesterday's. This service turns it into a table. Paste Booking.com hotel URLs, one per line, and each property comes back as a single wide row: the identifiers and location fields at the left, then a block of five columns for every room type - its name, its prices, the occupancy each rate was offered at, the room's facilities, and the booking conditions attached.

There is very little to configure, which is deliberate. This form has no limit box and no sort menu; the list of hotels is the whole input, and you size the run by how many you paste. Check-in and check-out dates are added automatically and come back in the row, so an export explains itself months later - in every row we hold the two dates were consecutive, a one-night quote. What you do need to set up first is a residential PROXY_URL. The service states plainly that Booking blocks free and datacenter IPs and that a residential address is needed for prices, and that your real IP is never used. Doing that before the first run saves you an empty one.

The wide layout is the point rather than a quirk. A row-per-rate file repeats the hotel on every line and has to be pivoted before it means anything; here two runs of the same hotel line up column for column, so a diff shows exactly which room type moved and by how much. It also makes the arithmetic pleasant: you are billed per row, a row is a whole hotel however many room types it carries, so the repeat runs that price monitoring actually consists of stay cheap.

The limits are stated plainly because they change what to expect. The column names and their order are read from the service's own column code and are dependable. The described values are not on the same footing: we hold thirteen run exports, six of which are an older shape that no longer matches this service and are ignored, and the seven current ones contain ten hotel rows - all of the same property, the form's own example hotel. On that sample price_range was empty on every row, stars returned four different values and two blanks for one hotel, latitude, longitude and city were missing on some rows, and one run returned every room's prices empty while the other room columns were filled. Currencies and room-size units both varied between runs, so this page promises neither. Run the free tier against a hotel you actually care about and read your own first row; your first 500 cost nothing and need no credit card. See pricing for current rates.