How to Scrape Agoda Hotel Pricing for Asia (2026)

—

Agoda prices the same Bangkok hotel differently depending on whether you’re browsing from Singapore, Germany, or a US datacenter IP — and that gap can be $30+ per night. if you want to scrape Agoda hotel pricing for Asia at any meaningful scale, you need to understand why that variance exists, how Agoda’s anti-bot stack works, and what scraping approach survives it in 2026.

what data agoda exposes and where it lives

agoda surfaces two main data surfaces: the search results page (SRP) and the property detail page (PDP). the SRP returns a list of hotels with headline prices, star ratings, review scores, and availability flags. the PDP goes deeper — room types, cancellation policies, per-night price breakdowns, promotions, and the “genius” member price layer.

for competitive price intelligence, you typically want both: SRP for breadth (scanning 200+ properties across a city in one pass), PDP for depth (tracking all room tiers on a specific property over time). the data is rendered client-side via React, so a plain HTTP GET returns a skeleton page — actual pricing lives in XHR calls made after the initial load, which is where most scrapers break.

the JSON payloads from those XHR calls are clean and structured. a typical property object looks like:

# agoda search results XHR (simplified schema)
{
  "propertyId": 1234567,
  "propertyName": "Pullman Bangkok Hotel G",
  "starRating": 5,
  "reviewScore": 8.4,
  "reviewCount": 12041,
  "pricing": {
    "currency": "USD",
    "displayPrice": 142.00,
    "strikethroughPrice": 189.00,
    "memberPrice": 128.00,
    "isAvailable": True
  },
  "location": {
    "cityId": 14958,
    "countryId": 197
  }
}

the XHR endpoint pattern is https://www.agoda.com/api/en-us/pageparams/property?... with a mix of query params and a JSON POST body. capture this via browser devtools on your first pass — it changes with Agoda’s deploys.

agoda’s anti-bot stack in 2026

agoda runs Akamai Bot Manager on all primary endpoints. the fingerprinting is aggressive: it checks TLS fingerprint (JA3/JA3S), canvas/WebGL fingerprint, navigator properties, timing patterns between requests, and mouse/scroll events on the SRP. requests from datacenter IPs are challenged immediately — you’ll get a 403 or a silent redirect to a CAPTCHA interstitial.

the two most common failure modes:

silent empty results: agoda returns HTTP 200 with a valid page shell but zero hotel listings. this is a soft block from the Akamai layer, not an HTTP error. scrapers that only check status codes miss this entirely.
price displacement: agoda geo-gates pricing. a Thai residential IP sees THB pricing and local promotions. a US datacenter IP either gets blocked or sees inflated USD rates that don’t reflect local market reality.

this is a harder problem than what you’d face scraping Hotels.com pricing across markets, where geo-gating is less aggressive on non-Asia routes. for Agoda, getting accurate Southeast Asia pricing requires being topologically inside Southeast Asia.

the recommended scraping stack

playwright + residential proxies is the only approach that consistently works at scale in 2026. here’s the practical setup:

launch a Playwright browser with a real Chrome user-agent and disable navigator.webdriver
route traffic through rotating residential proxies in the target country (SG, TH, ID, or VN depending on your market)
let the page fully load — wait for the XHR pricing calls to complete, not just networkidle
intercept the XHR response directly rather than parsing the DOM

from playwright.async_api import async_playwright
import asyncio, json

async def scrape_agoda_srp(city_id: int, check_in: str, check_out: str, proxy: str):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            proxy={"server": proxy},
            args=["--disable-blink-features=AutomationControlled"]
        )
        ctx = await browser.new_context(
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36",
            locale="en-SG",
            timezone_id="Asia/Singapore"
        )
        page = await ctx.new_page()
        await page.add_init_script("Object.defineProperty(navigator, 'webdriver', {get: () => undefined})")

        results = []
        page.on("response", lambda r: results.append(r) if "pageparams/property" in r.url else None)

        await page.goto(f"https://www.agoda.com/search?city={city_id}&checkIn={check_in}&checkOut={check_out}")
        await page.wait_for_timeout(4000)  # let XHR calls fire

        await browser.close()
        return results

set locale="en-SG" and timezone_id="Asia/Singapore" — Agoda’s pricing logic factors in locale alongside IP. for Thai inventory specifically, swap to th-TH / Asia/Bangkok to surface local member rates.

proxy strategy and rate limits

proxy type	block rate (datacenter)	block rate (residential SG/TH)	cost per GB	recommended for
datacenter	~90%	—	$0.50-1	not viable
residential (rotating)	—	~8-12%	$3-8	SRP scraping, city scans
residential (sticky session)	—	~4-6%	$4-10	PDP deep dives, multi-page flows
mobile 4G (SG SIM)	—	~1-3%	$15-30	highest accuracy, low volume

for a city-level SRP scan (say, all Bangkok hotels for a 2-night window), a budget of 2-3GB of rotating residential proxy bandwidth covers roughly 500-800 property records with buffer for retries.

rate limit your requests to 1 request per 4-6 seconds per proxy session. agoda’s Akamai layer tracks velocity per session cookie, not just per IP — cycling IPs every request without rotating the cookie jar triggers pattern detection.

Trip.com’s Asia inventory has a similar XHR intercept pattern but is less aggressive on session fingerprinting, which makes concurrent scraping easier there. Skyscanner flight data follows a comparable Akamai pattern but on a much tighter rate limit — Agoda is actually more forgiving on volume if your session looks clean.

parsing, storage, and common gotchas

a few concrete issues you’ll hit in production:

currency normalization: agoda returns prices in the user’s local currency based on IP + locale. if you scrape TH with THB and SG with SGD, you need an FX normalization layer. pull rates from a daily ECB/FreeCurrencyAPI snapshot, not live, or your time-series comparisons break on volatile days.
availability flags vs. price null: a hotel can appear in SRP with isAvailable: false and no price. store the null explicitly — don’t skip the row. “unavailable” is a signal, not missing data.
review score drift: agoda’s review score updates in near-real-time. if you’re tracking competitive positioning, scrape scores on a consistent weekly cadence, not ad-hoc.
member price layer: the memberPrice field only populates if your session has Agoda Genius status cookies. for accurate price comparison you want both displayPrice (public) and memberPrice (logged-in). this requires maintaining authenticated browser sessions in rotation, which adds complexity. skip it unless you specifically need loyalty pricing.

for non-hotel rental inventory, Vrbo is worth pairing with Agoda data if your use case covers aparthotel and villa segments — Agoda has expanded its vacation rental listings in Bali and Phuket significantly since 2024.

the same anti-bot bypass principles covered here apply broadly to any high-value consumer platform — see this Temu anti-bot guide for a deeper breakdown of Akamai + PerimeterX stacking patterns that show up across e-commerce and travel verticals alike.

bottom line

for scraping Agoda hotel pricing in Asia, Playwright with rotating residential proxies geolocated to the target market is the only viable approach in 2026 — datacenter IPs are effectively blocked. intercept the XHR pricing payloads rather than parsing the DOM, keep session velocity under one request per 4 seconds, and normalize currencies at storage time. dataresearchtools.com covers this class of problem across travel, e-commerce, and marketplace verticals if you want to benchmark your approach against other OTA targets in the region.