Agoda is the hotel booking site of Asia, founded in 2005, headquartered in Singapore and Bangkok, part of Booking Holdings since 2007, and available in more than two dozen languages (Wikipedia, Agoda). It is also the site travelers most often accuse of showing them a different price than their friend across the border saw for the same room. Proxies for Agoda are the tool for reading those prices properly: from the country whose guests you care about, on the kind of connection they use, at a volume Agoda's bot management does not recognize as a machine.
We run a proxy network, and Agoda traffic reaches us from hotel revenue teams shopping their comp set across Asian source markets, from travel-data vendors and from price trackers. This is the practical page: why the price depends on the visitor, why a plain request returns nothing, how Agoda blocks, which proxy type fits and how to size it. The hotel-side buyer's guide is proxies for hotel rate monitoring, the sister site is proxies for Booking.com, and the sector background is in travel fare aggregation.
What proxies are best for Agoda?
Rotating residential proxies pinned to the country whose prices you want, driven through a headless browser that scrolls, with a sticky residential or ISP exit for any logged-in read and a mobile exit with a mobile user agent for app-only prices. Agoda flags datacenter IPs and non-browser request patterns quickly and rate-limits or challenges them before the listings render, so home connections and a real browser are both required. Datacenter proxies are for parser development only.
The price depends on who is looking
Agoda does not show one price for a room. It shows a price to a visitor, and travelers have been documenting the difference for years. A Tripadvisor thread titled "Beware of Agoda price differences" collects reports of the same room pricing differently by the country the visitor appears to be in (Tripadvisor forum); another documents app prices that differ from the website for the same booking (Tripadvisor forum); a FlyerTalk thread found the price depending on where the visitor was referred from (FlyerTalk). A location-spoofing app vendor with an obvious interest in the answer tested 30 hotels and reported a cheaper price from some other country for 26 of them (AnyGo); weigh the source, but the pattern matches what travelers report unprompted.
The mechanics are not a mystery. Agoda localizes the currency to the visitor. Its sister site Booking.com sells hotels Country Rates, discounts that are only visible to guests browsing from an IP address in the targeted country (Booking.com for Partners), and Agoda gives its own hotel partners rate plans and Agoda Special Offers to build in its YCS extranet (Agoda Partner Hub). Add login state and the app, and the price is a function of four things a scraper controls: the apparent country, the device, the session and the referrer.
For a hotel in Bangkok watching its comp set, the consequence is direct. The office connection in Bangkok sees Thailand's version of every competitor's price. The version shown to a guest booking from Seoul, Singapore or Sydney, the markets that fill the rooms, is a different read, and it takes an exit in each of those countries to collect it.
A 200 with nothing in it
The second Agoda-specific fact is technical, and it catches most first attempts. The search results are built in the browser. Crawlbase's guide puts it precisely: Agoda builds its search results through JavaScript and loads more property cards only as you scroll, so the initial HTML is a thin shell that fills in after the page's scripts run, and a plain HTTP request gets a response with status 200 and almost none of the listings in the body (Crawlbase, how to scrape hotel data from Agoda). Their working configuration renders the page and scrolls for up to 20 seconds to load the lazily rendered cards.
GET search page
status 200
Thin HTML shell
almost no listings
Scripts run
browser only
Scroll
cards load lazily
Prices readable
after ~20 seconds
That shape sets the cost model. Every Agoda search is a browser session with scrolling, which means bandwidth and browser time, and it means one IP has to hold for the whole render. It also means a success counter that checks the status code is lying to you: count a search as successful only when property cards are present in the rendered DOM.
How Agoda blocks you
Agoda flags automated traffic quickly: datacenter IPs and request patterns that do not look like a real browser get rate-limited, IP-blocked, or challenged before they ever reach the rendered content (Crawlbase). The order in that sentence is the practical one. The IP is judged first, and hosting ranges lose. Then the pattern: a client that opens 40 searches a minute, arrives with no cookies every time, or sends a handshake that does not match its user agent. The advice from the same guide is the advice we give: pace the requests, lean on rotation across residential addresses, and watch the status codes, because a run that starts returning non-200 responses is telling you the current rate or IP tier is no longer enough.
Which proxy type fits: residential, datacenter, ISP, or mobile
Datacenter proxies are judged first and lose first on Agoda. They are for developing a parser against saved rendered pages.
Rotating residential proxies are home connections from a large pool, pinned to the market, one per rendered search, rotated between searches. They pass the IP check, they read the country's version of the price, and on Agoda's Asian markets they matter more than usual, because a guest in Jakarta or Manila books from a home or mobile line and the price is built for that visitor. Our pool covers 100+ countries, which on Agoda means the markets that actually fill the rooms (background in what is a residential proxy).
ISP proxies are static residential addresses for logged-in reads, where the session has to stay on one IP through several pages.
Mobile proxies are carrier addresses shared by many phones. Agoda's app prices differ from the site, so a mobile exit with a mobile user agent is the honest way to read them, and it is the fallback for runs that keep drawing challenges.
| Agoda job | Proxy type | Why |
|---|---|---|
| Search and hotel pages across markets | Rotating residential, country-pinned | Reads each market's price; passes the IP check |
| Comp-set shopping from Asian source markets | Rotating residential per feeder country | The guest's country decides the price shown |
| Logged-in prices | Sticky residential or ISP | Session persists on one address |
| App-only prices | Mobile, mobile user agent | Device is part of the price |
| Parser development | Datacenter or free list | Saved pages, nothing at stake |
Free versus paid for Agoda
Free proxies fail Agoda twice over: they are shared datacenter addresses, which Agoda judges first, and they rarely stay alive for the 20-second render a search needs. For a manual look at another market's price, the currency and country settings on the page plus a single free exit from our free proxy list will sometimes do, and the free proxy checker confirms the exit country before you spend the render. For a schedule, paid residential behind a browser is the floor; ours starts at $0.44/GB pay-as-you-go with no KYC, so a first run across three markets costs cents.
Setting it up
Render, scroll, then read. Use Playwright or Puppeteer behind a residential exit (our guides: Playwright, Puppeteer), scroll the results for long enough to load the cards you want, and parse the DOM, not the initial HTML. Block images and fonts to cut bandwidth; keep the scripts.
Pin the market on the exit and on the page. Exit from the guest's country, and let Agoda choose that visitor's currency and language rather than overriding it, because the override is a signal and the default is the guest's real experience. Reading a hotel from four markets is four renders from four exits.
Rotate by state. Search and hotel pages are stateless: one residential IP per render, then a fresh one. Logged-in reads and app reads hold a sticky exit for the session; the difference is explained in rotating vs static residential proxies.
Count success by cards, not by status. A 200 with an empty shell is a failed read. Log the number of property cards per search and alert when it drops, because that is how a challenge or a rate limit shows up on Agoda.
How many IPs, and how fast
The unit is a rendered search, and the cost is the render.
Sizing (rotating residential, one refresh cycle):
searches/cycle = cities x check-in dates x markets
= 12 cities x 45 dates x 4 markets = 2,160 renders
per render = browser session with scrolling, ~20 seconds
bandwidth = trim to scripts and HTML; block images and fonts
One residential IP per render, a fresh IP for the next, gentle pacing.
Shop near-term dates daily and far dates weekly, and the render count falls by more than half. Our pricing is per gigabyte with no monthly minimum, which suits a job that scales with the season.
Staying unblocked on Agoda
- Home connection, real browser, both. Agoda judges the IP first and the pattern second; a datacenter exit under a perfect browser still loses the first check.
- Exit from the guest's country and let the site localize. Consistency is both the accuracy rule and the reputation rule.
- Carry cookies through a session, drop them with the IP. History inside a render, none across renders.
- Pace like a person. Nobody opens 40 hotel searches a minute; jitter the gaps and spread markets across the day. The checklist is in avoiding IP bans while scraping.
- Watch cards per search and non-200 rates together. Both fall before a block lands; slow down when either moves.
- Read the app layer honestly. Mobile exit, mobile user agent, mobile viewport. A desktop browser claiming to be a phone is a fingerprint mismatch.
The limits worth knowing
Proxies put an Agoda read in the right country on the right kind of line, and they spread a schedule so that Agoda sees guests rather than a monitor. They do not render JavaScript, they do not reveal a member price without a member account, and they do not change Agoda's terms of service. Where a partnership with Agoda is available, it is the better route for the data it covers.
What good proxies give you is the price a guest in each market is actually shown, on a schedule, without your own connection being flagged for asking. For a first look, our free proxy list and proxy checker are free. For a schedule, rotating residential at $0.44/GB pay-as-you-go, one exit per market and a real browser in front, is what reads Agoda.
Sources
- Wikipedia, Agoda, on founding, headquarters, ownership and languages.
- Crawlbase, how to scrape hotel data from Agoda, on client-side rendering, scrolling and how Agoda flags automated traffic.
- Tripadvisor forums, beware of Agoda price differences and Agoda app and website different price, traveler reports.
- FlyerTalk, Agoda.com pricing depends on where you were referred from.
- AnyGo, how to pay less on Agoda, 30 hotels tested, a vendor test, cited with that caveat.
- Booking.com for Partners, Country Rates, on IP-country visibility at the sister site.
- Agoda Partner Hub, how do I set up an Agoda Special Offers rate plan.