Proxies for Booking.com: the challenge page, the Demand API and country rates

Most people who reach this page search for a Booking.com proxy. Some want hotel data for a product or a report. Others hope that a proxy in another country will show a cheaper room. This page checks both hopes against what the company publishes and what its site did to our server. The short answer: for data, the company sells access through its Demand API and forbids bots and scripts without written permission. For prices, country rates exist, and the API takes the country of the traveler as a field.

What booking.com did to our server

We sent plain requests from our server in St. Louis on 27 September 2026, with a browser user agent and no cookies or JavaScript.

The 202 page asks the visitor to turn on JavaScript, so that it can check the visitor is not a robot. It loads a script named challenge.js and calls AwsWafIntegration. Both names come from the AWS WAF JavaScript API, and AWS documents its challenge as an answer with the status "202 Request Accepted" and a challenge script. So booking.com checks a visitor before it shows a search, even on the first request. We did not try to get past it.

What the Booking.com terms say

The customer terms, updated on 25 August 2025, are direct about bots and scripts. Section A15.2 applies "Whether or not you have a commercial purpose". It forbids users to "access, monitor, copy, scrape/crawl, download, reproduce, or otherwise use anything on our Platform using any robot, spider, scraper, other automated means, or automated assistants". That holds "for any purpose without the prior, express written permission of Booking.com".

Section A15.3 lists what makes the company block a visitor, or a bot. It names four suspicions:

• "conducting an unreasonable amount of searches";
• "using any device or software to gather prices or other information";
• "doing anything that places undue stress on our Platform";
• "using automated assistants (including AI-powered assistants) to access the Platform without express permission".

Section A18 adds that Booking.com may stop a user from booking or using the site for "fraud or abuse". It also says the company is "entitled to injunctive relief" against "the unauthorized use of automated means or automated assistants". The terms do not mention proxies or VPNs at all.

The robots file for all crawlers closes the booking steps, such as /book.html, /mybooking.html and /confirmation.html. It also closes internal paths such as /asapi/ and /c360-api/, and the map data under /hotelsonmap. It does not list the search results page. The terms decide anyway: robots rules only guide crawlers, and the terms ask for written permission.

The official route: the Demand API

Booking.com says it "offers more than 28 million reported accommodation listings" and is available in 43 languages. Partners reach that catalog through the Demand API. In the words of its guide, the API "gives your application access to Booking.com travel services, including accommodation, car rentals and attractions".

Access takes three steps, all before the first call:

• register as a Booking.com Managed Affiliate Partner;
• get access to Partner Centre, which your account manager opens "after signing the agreed contract";
• create an API key there, and note your affiliate ID.

Every request carries both. The key goes in the Authorization header as a bearer token, and the affiliate ID goes in the X-Affiliate-Id header. The guide adds that requests "with missing or invalid credentials return 401 Unauthorized", which is what our server got.

A partner can choose how deep to go. It can show content and send travelers to Booking.com to book. It can let them search and compare first, or it can build the whole booking on its own site. A search in the sandbox looks like this, with the values of the example in the guide:

curl --request POST 'https://demandapi-sandbox.booking.com/3.2/accommodations/search' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'X-Affiliate-Id: YOUR_AFFILIATE_ID' \
  --header 'Content-Type: application/json' \
  --data '{"city": -2140479, "booker": {"country": "nl", "platform": "mobile"},
           "checkin": "2026-11-06", "checkout": "2026-11-08",
           "guests": {"number_of_rooms": 1, "number_of_adults": 2}}'

The sandbox takes your normal key and affiliate ID. It runs on test data, so you can try requests "without creating real orders, bookings or charges".

The limits. Booking.com sets limits "on the number of requests a partner account can send per minute", and your account manager has the figure for your account. Past the limit, the API answers 429, and access is "temporarily restricted for a brief period (typically 1 minute)". The sandbox allows 50 requests a minute, and the car search allows 3,000.

So the API needs no proxy. It runs on your key and affiliate ID, and the limit belongs to your partner account, so more addresses do not add calls.

Why prices differ by country

Prices on the site can depend on the audience. The Booking.com guide for hotel software defines two targeted discounts:

• a country rate, "A discount only available to customers booking from a specific country or region";
• a mobile rate, "A device-specific discount only available to customers booking from a mobile device (mobile web or the Booking.com app)".

Genius rates add a third layer. The terms say "Genius rates are for members of the Booking.com Genius program" and that "Membership and rates are non-transferable".

In the Demand API, the partner states who the traveler is, in the booker part of each request. To get country rates, the guide says to set booker.country to the country code of the traveler. Rates for signed-in travelers need the value authenticated in booker.user_groups.

How the website itself decides where a visitor books from, we could not check. The Booking.com help pages for hotels answered our server with HTTP 202 and an empty page, and the Internet Archive has excluded them. The guide for hotel software speaks of "predefined geolocations" for country rates. The terms also say the default currency of a Wallet is "determined by your location, residency, or another currency we may elect".

When a proxy helps, and when it does not

It helps with one narrow job: seeing Booking.com in your own browser the way a visitor in another country sees it. A country rate is "only available to customers booking from a specific country or region", so the proxy is for looking, not for booking at that rate. A residential proxy in that country changes the address the site sees. Our residential traffic with country targeting starts at $0.44/GB. We did not test whether booking.com grants a country rate through a proxy, so treat what you see as a check, not a promise. Note too that the terms name software that gathers prices among the reasons to block a visitor.

It does not help with the rest:

• Hotel data. The terms forbid bots and scripts without written permission. Apply for the Demand API instead.
• The API itself. It runs on your key and affiliate ID, and the limit follows your partner account.
• Genius and mobile rates. They follow the account and the device, not the address.

We sell residential, ISP and mobile proxies, and every plan is on our pricing page. For the basics, see what a residential proxy is and when to choose rotating or static residential proxies. Our free proxy list and proxy checker cost nothing, and our page on free proxies for Booking.com tests the free route. If you track rates on sites that allow it, our pages on hotel rate monitoring and travel fare aggregation cover that work.

Booking.com and scraping in court

Booking.com has stood on the other side of this question. On 4 September 2020, Ryanair sued five online travel agents, Booking.com among them, over what it called "screen scraping" of its website. After a four-day trial, a jury found against Booking.com on two counts.

In January 2025 the judge granted Booking.com judgment as a matter of law. The law behind the claims requires at least $5,000 in loss, or in value, and the court found that Ryanair had not proved it. On 26 August 2025, Ryanair and Booking Holdings announced a partnership that brings Ryanair flights to Booking.com, KAYAK, Priceline and Agoda. A proxy changes nothing in a dispute like this one.

The limits of this page

We made plain requests without JavaScript or cookies, from one server in the United States. So we did not see a search result, and we did not test how booking.com treats a visitor through a proxy in another country. A script also shows a different TLS fingerprint from a browser, so booking.com may answer a browser differently. We could not read the help pages for hotels, so how the website locates a visitor is not confirmed here. We are not a partner, so the example call is untested. The terms and the guides can change, and this page is due for a check by 27 December 2026.

Sources

We read every source below on 27 September 2026.

• Booking.com, Customer terms of service, updated 25 August 2025.
• Booking.com, robots.txt and About Booking.com.
• Booking.com for Developers, the Demand API guide: About the Demand API, Prerequisites, Authentication, Rate limiting, Sandbox, Try the Demand API and Discounts.
• Booking.com for Developers, the Connectivity guide on promotions.
• Amazon Web Services, AWS WAF Developer Guide: CAPTCHA and Challenge action behavior and the JavaScript API.
• United States District Court for the District of Delaware, Ryanair DAC v. Booking.com B.V., No. 20-1191, Memorandum Opinion and Order, 22 January 2025.
• Booking Holdings, Ryanair and Booking Holdings Sign Partnership Agreement, 26 August 2025.
• Our requests to booking.com and the Demand API from our own server, 27 September 2026.

More pages in this series: proxies for Expedia, proxies for Airbnb, proxies for Agoda, proxies for Kayak and proxies for Priceline. Our page on proxies for booking is about reservation systems for restaurants, campsites and appointments, not this site.