Skip to main content
Agoda endpoints require a paid plan (Starter or higher). Without one, these endpoints return 402 plan_upgrade_required. See Pricing for details.

​
Endpoints

  • GET /v1/agoda/search — Search hotel availability for a destination and stay window.
  • GET /v1/agoda/search/crawl — Queue a multi-page Agoda search as an async job (up to 25 pages).
  • GET /v1/agoda/property — Retrieve structured property details and per-room rates.
  • GET /v1/agoda/reviews — Retrieve the review score breakdown and individual review cards.
  • GET /v1/agoda/reviews/crawl — Queue the same reviews capture as an async job, with no deadline.

​
Resolving a property by ID

/v1/agoda/property and /v1/agoda/reviews accept either a full url or a property_id. If you only have property_id, you must also pass city_id — Agoda’s own suggest endpoint only does fuzzy text matching, not ID lookups, so there’s no way to resolve a property’s city from property_id alone. Every GET /v1/agoda/search response carries the resolved city as meta_data.resolved_city_id for exactly this purpose:
Passing a full url instead skips this requirement entirely, since the property (and its city) are already fully identified by the URL.

​
Pagination

Agoda has no URL-based pagination — there is no page query parameter Agoda’s own site respects. Passing page (greater than 1) on /v1/agoda/search or /v1/agoda/reviews instead drives a real, synchronous capture-and-replay session: Scrapio simulates the pagination click Agoda’s own UI requires, intercepts the resulting dynamically-header-guarded request, and replays it with the patched page number — all within the same request/response cycle, no job polling required. Because it drives a real interaction, it’s billed at 25 credits instead of the base 15. For a larger page range than fits comfortably in one inline request’s timeout budget, GET /v1/agoda/search/crawl queues the same real capture-and-replay mechanism as a background job (up to 25 pages from start_page), mirroring Booking’s /v1/booking/search/crawl. Unlike Booking’s crawl, every page — including the first — goes through the capture-replay path and is billed at the same interact rate, since Agoda has no cheaper plain-fetch page 1. It also does not accept sort_by/min_price/max_price/stars/min_review_score: Agoda’s search filters only apply via a single interact click session with no mechanism that carries across a multi-page crawl.

​
Individual review cards

Unlike Booking.com, GET /v1/agoda/reviews returns both the review score breakdown and individual review cards from a single plain page load — there’s no include_review_details opt-in or separate interact-session billing tier. Page 1 is always 15 credits; page beyond 1 is billed at 25 credits for the same real-interaction reason as search pagination. Capturing that data reliably can take longer than an HTTP request can safely wait — GET /v1/agoda/reviews bounds itself to stay under the ~100s edge timeout and returns quickly with an empty reviews/score_breakdown rather than hang if that budget runs out. If you need real review data reliably rather than a fast response, use GET /v1/agoda/reviews/crawl instead: same parameters, same result shape, but it runs as a background job (poll GET /v1/jobs/{id}) with no deadline.

​
Hotel monitors

Watch an Agoda property at fixed dates and occupancy, and get notified only when the price actually changes — including cross-provider rate-parity monitoring against Booking.com. See Hotel Monitors.