BEST Agoda Scraper
Pricing
from $2.00 / 1,000 results
Two modes: search a city for every hotel + homestay, or monitor specific properties across dates with price-change deltas and next-available on sold-out. Each row: tax-inclusive price, availability, reviews, geo. 32 currencies verified end-to-end — no silent USD fallbacks. Covers Agoda Homes.
Paste an Agoda city URL (copy from the browser address bar after choosing a destination on agoda.com). The scraper finds every hotel + homestay in that city and returns one row per property × check-in date. Example: https://www.agoda.com/city/singapore-sg.html. You can also paste a numeric cityId as a string. Full-text queries like 'Bangkok' do NOT work. Use the city URL or cityId.
Alternative to Search destinations for power users who already know Agoda's internal cityId (e.g. 4064 = Singapore, 5085 = Tokyo). Same output as destination search.
List of specific Agoda property URLs to monitor. Use this when you want rich per-property detail (amenities, host info, review themes, images) across a date range. Accepts canonical //hotel/.html URLs. Leave empty if you're using Search destinations above.
Which dates to scan. startFrom = 'today' or a YYYY-MM-DD date. scanDays = how many consecutive check-in dates to cover. lengthOfStay = nights per booking. stride = step between check-ins (1 = every day, 7 = weekly snapshots). Example: scanDays=14, stride=1 → 14 rows per property covering the next two weeks.
Flexible-traveler mode. Also scans N days before AND after each check-in in your dateMatrix, so you can see how price shifts if the trip moves by a day or two. With one target date, flexDays=2 produces 5 rows (day-2, day-1, day, day+1, day+2). The property summary tells you which window is cheapest. Cost scales with rows. Default 0 means off.
Number of adult guests. Affects pricing and availability (Agoda hides rooms that can't fit the party).
Number of rooms to book. Most travel searches use 1.
Number of children. Combined with adults to determine the occupancy filter Agoda applies.
ISO currency code for prices in the output. 32 currencies verified end-to-end against Agoda's pricing endpoint: USD, EUR, GBP, SGD, HKD, AUD, NZD, CAD, CHF, JPY, CNY, KRW, TWD, INR, THB, MYR, IDR, PHP, VND, AED, BHD, OMR, ZAR, BRL, ARS, NOK, SEK, DKK, PLN, CZK, AFN, FJD. Other codes fall back to USD with a clear [currency] warning in the run log and the row stamped USD (never a silent mismatch). Agoda performs the FX conversion server-side at their display rate, not interbank mid-market.
Controls the language of text fields in the output (property names, descriptions, review snippets). Common values: en-us, en-gb, de-de, fr-fr, ja-jp, zh-cn.
Cap how many properties to return per (city × check-in date). 45 = one page (cheapest). 200+ triggers pagination and scales cost linearly. Only applies when using Search destinations / Search by cityId.
How Agoda ranks results. Agoda caps unique properties per sort at roughly 650-1000 per city, so different sorts expose different inventory. Running all four sorts (Recommended, PriceAsc, PriceDesc, ReviewScore) back-to-back with skipSeen=true typically reveals 1.5 to 2 times more unique hotels than a single sort.
Dedup across runs without setting up your own storage. When true, the actor remembers every propertyId it already returned for each city (in a private per-account store) and suppresses duplicates before they hit the dataset — so you never pay twice for the same hotel. Pair with sortBy to fan out across all four sorts: run 1 grabs the bulk, runs 2-4 only pay for new inventory each sort surfaces.
Suppress emission for any propertyId in this list. Works in addition to skipSeen; both inputs are merged. Use this when you have your own database of IDs (e.g. a UI that tracks scraped hotels). The actor still fetches the search pages (compute cost unchanged) but drops matching rows before pushData so you do not pay the per-row dataset charge.
Kept for backwards compatibility. The actor always uses the same fast JSON API path today, so this setting has no effect. Older saved configs with api or browser are accepted and silently routed to the default. Leave as is.
How many properties to scrape in parallel. Higher is faster but raises the chance of rate limiting. 5 is a safe default.
How many (city, check-in date) search pools to scan in parallel. A pool is one city for one check-in; pages within a pool stay sequential because Agoda's pagination needs the previous page's token. Default 5 cuts wall-clock roughly linearly on multi-city or multi-date runs. Raise carefully: too high and Agoda may rate-limit.
Caches property name, rating, amenities, and host info in a named key-value store so repeat runs skip the full property detail fetch. Great for hourly price monitoring schedules. 168 = one week. Set to 0 to disable.
Which proxy to use. The default (Apify Proxy, residential) is a safety net for the initial page load where Agoda blocks datacenter IPs. The price-monitoring API calls underneath use cheaper datacenter proxy automatically. You don't need to change anything unless you bring your own proxy pool.
Pins proxy traffic to one country so Agoda's response is reproducible. This matters. Agoda serves different base prices by country (geo pricing), and forces tax inclusive display in EU, UK, and AU (regulated) while showing pre tax prices to US and most APAC markets. Pick the market you want to monitor. Default "US" gives pre tax USD. Leave blank to let proxy rotate freely. Not recommended, because it breaks cross run price deltas.
Planning mode. When a scanned date is sold out, annotate the row with the nearest available check-in BEFORE (daysOffset -1, -2, -3) and AFTER (+1, +2, +3) drawn from the same scan. Zero extra API cost, because it uses only dates already scraped in this run. Your scanDays window must actually cover the neighbors for annotations to appear (for example, scanning a single sold-out date gives no neighbors). Perfect for 'is the trip shiftable?' answers: if Monday is sold out but Sunday or Tuesday is open, the row tells you. Populated fields: nextAvailableBefore and nextAvailableAfter, each with {checkIn, checkOut, nights, priceNightly, daysOffset}. Default off.
Price monitor mode. When enabled, a quote row is emitted to the dataset ONLY if (a) it's the first time we've seen this (property, check-in date, currency, occupancy, proxy country), meaning no prior run to compare against, or (b) the nightly price moved vs. the prior run, or (c) availability transitioned (for example, available to sold-out). Unchanged rows are silently skipped. The run still scrapes every date (cost is unchanged). It just suppresses dataset writes for no-op rows. Perfect for hourly schedules where you only want to process diffs. Summary and run-report rows always emit. The FIRST run with changedOnly=true emits everything (no prior state). Subsequent runs emit only changes. Count of skipped rows is in run-report.totals.rowsSkippedUnchanged.
Threshold in the run's currency (see currency). When any available quote row has nightly price strictly below this, the row is recorded in the run's key-value store under PRICE_ALERTS (array of {propertySlug, checkIn, priceNightly, threshold, savingsVsThresholdPct, priceChangePct}). A boolean flag HAS_PRICE_ALERTS is always set so run-complete webhooks can gate on one key. Leave blank or 0 to disable. Typical recipe: schedule the actor hourly with changedOnly: true + alertBelowPrice: 120, then wire an Apify webhook that fires only when HAS_PRICE_ALERTS=true.
Routes the price monitoring API calls (date fan out and /graphql/property) through Apify's datacenter proxy instead of residential. About 8 times cheaper bytes, and validated as byte identical to residential on both endpoints as of 2026-04-16, so this is the default. Note: the initial property discovery page load still uses residential regardless of this flag, because Agoda gates datacenter IPs on that page. Set to false only if you need geo accurate local pricing on every date cell (rare, because Agoda's final booking flow price is authoritative either way).
Before each run, probe 3 known-stable properties and check that critical fields (name, price, rating, etc.) come back populated. If all 3 return null on the same field, Agoda likely changed their API and the run is aborted before emitting bad data. The result is cached in a named key-value store for this many minutes so frequent runs amortize the probe. 0 disables the canary entirely. Default 60 (one probe per hour across all runs). Adds about $0.001 per run the first time each hour.
