Proxies for Booking.com: Reading the Price a Local Guest Actually Sees

Booking.com is the largest hotel booking site on earth, and it decides what price to show you before you have typed a single letter. The currency comes from your IP address. Some discounts only exist for visitors whose IP sits in a country the hotel chose to target. Others only appear once you log in, or only on the mobile app. Proxies for Booking.com exist because of that design: to read the price a guest in Madrid or Bangkok actually sees, the request has to leave from an IP in Madrid or Bangkok, and to read thousands of those prices on a schedule, the requests have to look like thousands of separate guests instead of one machine.

We run a proxy network, so we see both ends of this job: what people buy to collect Booking.com data (hotel rate monitoring for a revenue team, market research for an investor, price tracking for a deal site, a rate-shopping product that sells to hotels) and what comes back as a support ticket once a setup starts eating challenges. This page is the practical version for Booking.com specifically. The sector-wide background lives in travel fare aggregation, the sibling sites in proxies for Expedia and proxies for Airbnb, and the hotel-side buyer's guide in proxies for hotel rate monitoring. One note on naming: our older post on proxies for booking is about reservation systems (restaurant tables, campsites, appointments), not this site.

What proxies are best for Booking.com?

Rotating residential proxies pinned to the country whose prices you want, because Booking.com localizes currency and several discount layers by the visitor's IP country, and because its bot management challenges datacenter ranges long before it challenges a home connection. Hold a sticky residential or ISP exit for any stateful flow (a logged-in Genius account, a walk through the booking funnel to the final price). Datacenter is only for light, occasional checks, and mobile is the rare last resort.

Three price layers, and only one of them is about the hotel

Most scraping guides treat the Booking.com price as one number that varies by date. It is closer to a stack, and the stack is the reason proxies matter here more than on an ordinary retail site.

The first layer is currency. Booking.com picks the display currency from the client IP's geographical location (ScrapFly, how to scrape Booking.com). You can override it with the selected_currency parameter, and the response sets cookies that keep that currency on later pages, but the default a real guest sees is decided by where their connection sits.

The second layer is the one almost nobody outside the hotel industry knows about. Booking.com sells its hotel partners a product called Country Rates: targeted discounts aimed at guests from chosen markets. In Booking.com's own partner documentation, country rates are only visible to guests using Booking.com from an IP address matching the country the hotel is targeting (Booking.com for Partners, Country Rates; the wording is quoted in Hotel Link's guide to the feature). The discount stacks on top of the hotel's other promotions and on Genius. A hotel in Lisbon can quietly offer German guests 10 percent off for the whole year, and a scraper reading Lisbon prices from a Dutch datacenter will never see it. The number it collects is real, but it is not the number a German guest is shown.

The third layer is about identity rather than place. Genius member prices appear once you are logged in, and Mobile Rates are shown to guests on the mobile app or mobile site. Neither depends on the exit country, but both depend on session state, which decides whether you can rotate freely or have to hold one IP for a while.

For a hotel watching its competitors, this stack is the whole problem: your own office IP shows you one version of the market, and the version your guests see may carry a discount you cannot detect from where you sit. That is why rate-shopping products shop from residential exits in the guest's country, and why we wrote the hotel-side version of this page separately.

Why the data matters: scale, and a market that just changed

Booking.com reports more than 28 million accommodation listings, including over 6.6 million homes, apartments and other unique places to stay, available in 43 languages (Booking.com, about). It is part of Booking Holdings, alongside Agoda, Kayak and Priceline. For most of the world it is the reference price for a hotel room, which is why hotels, aggregators and analysts all read it.

Two things made reading it more valuable recently. The European Commission designated Booking a gatekeeper under the Digital Markets Act on 13 May 2024, with obligations applying from 14 November 2024 (European Commission), and Booking removed its parity clauses for properties in the European Economic Area from 2 December 2024 (Tourism Review). Those clauses used to stop hotels from selling cheaper on their own sites than on Booking.com. With them gone, the gap between a hotel's direct price and its Booking.com price is a live number that changes daily, and both sides want to measure it.

The other change is legal, and it cuts the other way. Ryanair sued Booking.com over scraping of Ryanair's own site. A Delaware jury found in July 2024 that Booking.com had violated the Computer Fraud and Abuse Act, with damages of exactly $5,000, the statute's minimum threshold. In January 2025 the judge granted Booking.com judgment as a matter of law, ruling that Ryanair had not proven $5,000 of loss under the statute (Technology & Marketing Law Blog). Ryanair appealed, then dropped it when the two companies signed a partnership agreement on 26 August 2025 that put Ryanair flights on Booking.com, Kayak, Priceline and Agoda (Booking Holdings). The lesson for anyone scraping Booking.com is not that scraping is safe. It is that the largest travel company in the world spent five years in court over it, and that proxies change nothing about the legal question.

How Booking.com blocks you

At small volume, Booking.com serves plain HTML with the property cards in it, and a careful script with a normal browser header set reads it fine. At scale, ScrapFly's own guide puts it plainly: Booking will start to either block you or serve captchas, which hinders or completely disables the scraper (ScrapFly). Scraping-tool vendors report both Akamai and HUMAN (formerly PerimeterX) signatures on Booking.com pages (Automatio), which means the checks run at the edge on the TLS handshake and header order before your request reaches a page, not only on the IP.

Three behaviours draw the challenge fastest. Datacenter IP ranges, which commercial bot management distrusts by default. A request rhythm that looks like a monitor (the same city, every hour, on the clock). And a client that throws away the cookies Booking.com hands it, because a real guest carries a session across pages and a scraper that starts fresh every request does not. The GraphQL endpoint that powers the search page, booking.com/dml/graphql, expects the same session cookies and headers the page itself sends; call it bare and it fails.

Which proxy type fits: residential, datacenter, ISP, or mobile

Datacenter proxies are cheap and fast, and on Booking.com they are the first thing challenged. Keep them for a handful of manual checks or for testing your parser, never for a scheduled run. They also fail the Country Rate test: a datacenter IP in Germany is still a datacenter IP, and it is not the connection a German guest books from.

Rotating residential proxies are real home connections drawn from a pool, a fresh IP per request or per short sticky window, pinned to a country. They pass the reputation checks that turn datacenter away, and they are the only exit that reads Country Rates the way the targeted guest does. This is the workhorse for Booking.com search and hotel pages (background in what is a residential proxy). Metered by the gigabyte, and Booking.com pages are heavy, so trim what you download.

ISP proxies are static residential IPs on datacenter hardware: one address that does not change, registered to a consumer ISP. That is what a logged-in Genius account or a walk through the booking funnel needs, because a session that hops countries mid-flow gets dropped or flagged.

Mobile proxies are carrier IPs shared by many handsets. Booking.com sells Mobile Rates, so a mobile exit plus a mobile user agent is the honest way to read those, but most collection jobs never need the tier.

Free versus paid for Booking.com

A free proxy from a public list will open one Booking.com search page from another country, sometimes, and that is a useful thing when all you want is to see whether a price differs in Spain. Our free proxy list refreshes every few minutes across 100+ countries, and the free proxy checker confirms an IP is alive and exiting where it claims before you waste a request. What free cannot do is sustain a schedule: the working pool is overwhelmingly datacenter space, the addresses die within minutes, and Booking.com challenges shared datacenter IPs on sight. We measured exactly how far a batch of free proxies gets against Booking.com in free proxies for Booking.com. For anything that runs more than once, paid residential is the floor, and ours starts at $0.44/GB pay-as-you-go with no KYC, so a test run costs cents.

Setting it up

Start with the URL, because Booking.com puts most of the search state in it: ss (the destination), checkin and checkout, group_adults, no_rooms, group_children. Add selected_currency if you want to force a currency rather than inherit the exit's. Fetch the page once through your proxy, keep the cookies it sets, and reuse them for the rest of that session, because that is what a browser does and what the GraphQL endpoint expects.

Match the exit country to the question you are asking. If you want the price a Brazilian guest sees for a hotel in Rome, exit from Brazil, not Italy. Country Rates follow the guest's IP, so the exit country is the guest's country, and reading the same hotel from three markets means three runs, not one run with a currency switch.

Decide rotation by state. Search and hotel pages are stateless: rotate a fresh residential IP per request so no address builds up a monitor's signature. Genius prices and funnel walks are stateful: pin one exit for the minutes the flow takes (we explain the split in rotating vs static residential proxies). Mixing the two on one pool is the most common setup mistake we see, because a rotating pool logs you out of Genius on the second page.

Prefer HTTP requests over a browser where the page allows it. The property cards are in the HTML, and pagination runs through the GraphQL call ScrapFly documents, so a well-formed request client with realistic headers, cookies and TLS is lighter and less detectable than a headless browser. When you do need a browser, Playwright or Puppeteer behind a residential exit is the setup that holds.

How many IPs, and how fast

Booking.com grids grow faster than people expect. Ten cities, 60 check-in dates and three lengths of stay is 1,800 search pages per refresh, and each search page can lead to 20 or more hotel pages. Size from that request count and the rate a single IP tolerates, not from the number of hotels.

Sizing (rotating residential, one refresh cycle):
  search pages   = cities x check-in dates x lengths of stay
                 = 10 x 60 x 3 = 1,800
  hotel pages    = search pages x hotels opened per page
                 = 1,800 x 20 = 36,000
  requests/cycle = ~37,800 before retries

Throughput is the pool's job, not one IP's:
  spread 37,800 requests across many residential exits,
  keep each exit under the rate that draws a challenge,
  and buy bandwidth for the pages (they are heavy: trim images and scripts).

On a pay-as-you-go plan you are buying gigabytes, so the number that matters is page weight times requests. Request only the HTML, skip assets, and cache hotel pages that do not change between cycles. Our pricing has no monthly minimum and the balance does not expire, so a weekly refresh costs the same per page as a daily one.

Staying unblocked on Booking.com

• Exit from the guest's country, on a home connection. It is both the accuracy rule and the reputation rule, and it is the single change that fixes most Booking.com setups.
• Carry the session. Keep the cookies from the first response for the rest of that run. A client that discards them looks like nothing a browser ever does.
• Match the TLS and header profile to a real browser. Edge bot management fingerprints the handshake before it reads the IP (see TLS fingerprint). A clean residential IP with a Python default handshake still stands out.
• Pace and jitter. No guest opens 30 hotels a minute. Randomize the gaps and spread the schedule; the general checklist is in avoiding IP bans while scraping.
• Watch the challenge rate, not just the error rate. A 200 response can still be a challenge page. Check for the property cards in the body and count a miss when they are absent, or you will run for a week collecting empty pages.
• Use the sanctioned route where it exists. Booking.com's Demand API is available to affiliate partners who send it bookings. It is not a public price feed, but if you qualify it removes the whole problem for the data it covers.

The limits worth knowing

A proxy solves geography and reputation. It makes your request arrive from the country whose price you want, on the kind of connection a guest uses, and it spreads a schedule across enough addresses that no single one looks like a monitor. It does not fix a client that discards cookies, a handshake that announces a script, or a schedule that runs on the clock. It does not make the terms of service go away, and it does not change what a court would say about your particular use. Anyone selling Booking.com proxies that "cannot be detected" is selling a story.

What good proxies give you is a fair, unflagged read of the market as guests see it, in every country you care about. For learning and one-off checks, start free: our free proxy list and proxy checker cost nothing. When the job runs on a schedule, rotating residential at $0.44/GB pay-as-you-go, pinned to the guest's country, is what holds against Booking.com, with a static ISP exit for the logged-in and funnel work.

Sources

• Booking.com, about Booking.com, listings and languages.
• Booking.com for Partners, Country Rates, and Hotel Link, Country Rates from Booking.com, on IP-country visibility.
• ScrapFly, how to scrape Booking.com, on currency by IP location, the GraphQL endpoint and blocking at scale.
• Automatio, how to scrape Booking.com, on Akamai and PerimeterX signatures.
• European Commission, Booking must now comply with the Digital Markets Act.
• Tourism Review, parity clauses removed by Booking, 2 December 2024.
• Technology & Marketing Law Blog, court overturns a bad jury verdict against scraping, Ryanair v. Booking.
• Booking Holdings, Ryanair and Booking Holdings sign partnership agreement, 26 August 2025.