Booking.com is the one travel site where the proxy on its own returns nothing you can sell. On 28 September 2026 we fetched the home page through residential exits in Italy and the United States: a plain HTTP client received 3,962 bytes and 26 words, a full browser render received 857,992 bytes and zero words of content, and the numbers were identical from both countries. The setting for Booking.com proxies is therefore not a fetch mode. It is the Booking.com stays collector, which returned 20 priced properties for Rome in 5.9 seconds on the same afternoon.
The search term is asking for a scraper, not a proxy
Google autocomplete has nothing to say about Booking.com proxies: the phrase returns no suggestions in the United States, and "proxies for booking.com" completes to bots, browsing and Ticketmaster. The demand lives one word over. "Booking.com scraper" completes to scraper api, scraping policy, review scraper and price scraper, and the question people actually type is "can you scrape booking com".
The first page for that intent is hosted actors, four scraping-API vendor pages, a GitHub project and two Reddit threads titled, in effect, has anyone managed it. The best of the tutorials is 2,586 words long and correct about the mechanics: find hotel pages through the sitemaps, replicate the search endpoint, pin the proxy country to fix the currency. It never weighs a response. So we did, and the weight is the whole story.
26 words without JavaScript, 0 words with it
We audited booking.com/ twice from an Italian residential exit, once as a pure HTTP client and once fully rendered, then repeated both from the United States.
| Fetch | Exit | Bytes | Words | Title | Canonical |
|---|---|---|---|---|---|
| Plain HTTP | Italy | 3,962 | 26 | none | none |
| Rendered | Italy | 857,992 | 0 | Booking.com | Sito ufficiale | I migliori hotel... | /index.it.html |
| Plain HTTP | United States | 3,962 | 26 | none | none |
| Rendered | United States | see note | 0 | Booking.com | Official site | The best hotels... | / |
The plain HTTP body is 3,962 bytes and its h1 is the three words "JavaScript is disabled". There is no title tag, no canonical, no description and no JSON-LD. Twenty-six words arrive and not one of them is a hotel, and the response is the same size from Rome and from New York.
Rendering costs 216 times the bytes and 46.7 seconds of browser time, and it returns the head of the page and nothing else: a title, a canonical, zero words in the body. The browser is not a partial answer here. It is a more expensive way to get the same answer. If your pipeline currently opens a headless browser on Booking.com, that line item buys you a title tag.
What the second country shows is the only useful signal the home page gives away: Booking.com localises off the exit IP alone. From Italy the rendered title is Italian and the canonical is /index.it.html; from the United States the title is English and the canonical is the root. No Accept-Language header was sent. The site decided from the address, and it makes the same decision about currency, which is why the collector below pins the exit country and the currency explicitly instead of hoping.
What robots.txt and the terms say
booking.com/robots.txt is 39,491 bytes and 684 lines, and most of it is a map. Four hundred and thirty-four lines are Sitemap: entries pointing at gzipped indexes for hotels, cities, districts, landmarks, airports and themes. The rule section is thirteen user-agent blocks. Four crawlers are shut out entirely with a bare Disallow: /: psbot, TurnitinBot, NPBot and NPBot-1/2.0. Everyone else, including the wildcard, gets 77 disallow lines and 6 allow lines that fence off search fragments, availability endpoints and internal review indexes while leaving the hotel pages themselves crawlable.
The terms are stricter than the robots file. Clause A15.2 of the customer terms, in the Italian version we fetched, says that whether or not you have a commercial purpose you may not access, monitor, copy, extract, download or otherwise use any content on the platform using robots, spiders, scrapers or other automated means, and it names AI assistants that drive a browser as one of those means, without Booking.com's prior written permission. The same clause states that automated means may not be used to make reservations. That is one plain line and we will not argue with it: reading the public site with a script is something Booking.com's terms prohibit, and no proxy setting changes what a contract says.
The licensed route is the Demand API, version 3.1, for affiliate partners: REST over HTTPS POST, JSON responses, a production host at demandapi.booking.com/3.1 and a sandbox, authenticated with an affiliate ID and token. It covers accommodation search, availability, bookings and reporting. If you are a travel business that can pass the affiliate programme, that is the front door, and it comes with the permission attached.
The collector returns 20 priced properties in 5.9 seconds
For public price and availability monitoring, competitive sets and market research, we ran the booking_stays collector once on 28 September 2026 with the input Rome, Italy, check-in 20 October, check-out 22 October, two adults, one room, currency EUR, exit country Italy, up to 20 results. The run resolved the place to 41.89671, 12.48220, finished in 5.9 seconds and delivered 20 properties, none partial.
| Field | What the 20 rows contained |
|---|---|
| Two-night price | €440.61 to €4,595.32, every row priced |
| Struck-through price | present on all 20, implied discount 6% to 34% |
| Review score | 6.8 to 9.7 on 18 rows; 2 rows with no reviews yet |
| Distance from the searched point | 20 m to 100 m |
| Star class | 3 hotels (4, 4 and 5 stars); 17 apartments and rooms without one |
| Free cancellation | 5 of 20 |
| Breakfast included | 4 of 20 |
| Rooms left at this price | 1 on 17 rows, 2 on two rows, 3 on one |
Three details in that output matter more than the row count. Every price is for the exact dates you asked for and in the currency you asked for, because the collector sends both; the home page fetch above could not have told you the currency at all. The struck-through price and the discount percentage arrive as separate numeric fields, so the classic parser trap of two prices glued together in one text node does not exist here. And the distance is measured from a point, which means you can pass a street address instead of a city and get the properties around a specific hotel: that is how a competitive set is built, and it is why the run above clustered inside 100 metres of one square.
The other limit is stated on the collector page and worth repeating: it paginates 20 properties per page up to 100 per run. For a whole city you shape the job as many points, not one wide search, which is also what the best tutorial on the SERP recommends and what Booking.com's own result cap forces.
What a gigabyte buys on Booking.com, and what it does not
Every measurement above came through residential proxies on the Basic line at $0.80/GB, and the arithmetic looks like this, counting a gigabyte as 10^9 bytes:
| Request | Bytes | Requests per GB | Cost per request | What you get |
|---|---|---|---|---|
| Home page, plain HTTP | 3,962 | 252,397 | $0.0000032 | 26 words, no hotel |
| Home page, rendered | 857,992 | 1,165 | $0.00069 | a title tag |
| booking_stays, one property | billed per row | n/a | $0.02 | price, strike price, score, distance |
The first two rows are the point. A gigabyte of the cheapest residential bandwidth buys a quarter of a million responses to Booking.com that contain nothing, and 1,165 rendered responses that contain a title. The collector is priced per delivered property, failed rows are never billed, and the run above cost $0.40 for 20 rows. Budget by what a request yields, not by what it costs; our note on how much proxy data you need does the same arithmetic for targets where the fetch does return content, and how to price monitor covers the cadence once the rows are flowing.
Mobile exits at $2.30/GB and ISP addresses at $2.50/IP a month do not change any number in this post. The home page returned the same 26 words to every exit we tried; the barrier was JavaScript and a verification step, not the reputation of the address. Do not buy the expensive network for a surface that never asked about your IP.
The setting that works on Booking.com
Network: residential, Basic line at $0.80/GB, and only underneath the collector; a raw fetch of the site is not worth routing through any network. Fetch mode: neither engine: tls nor rendered, because they return 26 and 0 words respectively; the fetch that works is the booking_stays collector at $0.02 per delivered property. Country to pin: the market whose prices you want, passed as both the exit country and the currency, because the site localises title, canonical and currency off the IP alone: Italy gave us /index.it.html and euros, the United States gave the root and English. When the proxy is not enough: on this target that is always, and the collector answered with 20 rows in 5.9 seconds; for rate comparison across sellers, the Google Hotels collector returns the same stay from the metasearch side, and for anything else on the domain the web scraping API with render is the fallback, with the numbers above telling you what to expect, and every account gets $2 of free API usage per month, which is 100 delivered properties before you pay anything.
The same measurement on the neighbouring platforms lands differently: Airbnb serves its listings inside a hydration island that a plain fetch can read, and Kayak hands a no-JavaScript client 2,451 words. Booking.com is the one that hands it 26.