Agoda

Return the exact per-room-type price a real guest sees on Agoda's own site — not a metasearch or commission-inflated affiliate price. Submit a job, receive a job_id, poll for the result.

Base URL: https://api.scrapeguys.com · Auth: X-API-Key: gsk_… with the ota:agoda scope · See the Overview.

Submit a job

Addressing an OTA by number

Anywhere an OTA name is accepted — ota here, and each entry of otas on Rate Shop — you may send a numeric channel code instead:

The same table is served at GET /otas/, so an integration can read the mapping at runtime rather than transcribe it — an OTA numbered later then appears on its own.

Quoted ("1") and bare (1) both work. Names and aliases keep working exactly as before, and ota always echoes the canonical name, never the number — a job submitted as "ota": 2 comes back as "ota": "makemytrip". The number is in result.ota_code beside it, so an integration keyed on these numbers need not map ota back itself. In a rate shop, mixing forms is fine and a code and its name are recognised as the same OTA rather than billed twice.

result.ota_code shipped 15 September 2026: every result — on /ota-price/ and on each row of Rate Shop — now carries the OTA's numeric channel code alongside ota, including on failed jobs. 4 and 5 (expedia, goibibo) were added 21 September 2026 — before that both answered null.

OTA Directory

Every OTA this API prices, with the numeric code that addresses it, the aliases accepted for it, the endpoints that actually offer it, and whether your key is scoped for them. It's the machine-readable form of the table above, published so an integration can read the mapping at startup instead of hard-coding it. Costs 0 units.

No query parameters. Any active key may call it — it carries no scope of its own, because it's the same contract this page publishes to every client.

Rows are ordered by code.

Errors — 401 (missing, unknown or deactivated key).

Identifying the hotel

A request identifies its hotel one of three ways.

By name (hotel_name + city) is the default — resolved through Agoda's own search and picked by us. It works without you knowing anything about Agoda, and is what every existing integration uses.

By Google Place ID (place_id) is the recommended way to pin a portfolio. One id identifies the property across Agoda, Booking.com, MakeMyTrip and Goibibo, so you keep a single key per hotel instead of four. The first request for a place still goes through Agoda's own search — there's no other way in — but the id that actually returned a price is then pinned, so every later request for that place_id addresses the same property directly. A pin is written only when Agoda names the property and that name agrees with the Place ID's own; otherwise the job still returns prices and the next request resolves again. Send hotel_name alongside it if you have it — it's used as the search text for that one resolution; without it we look the name up from the Place ID itself.

By Agoda's own id (ota_hotel_id, its numeric propertyId, e.g. "16082488") is the most direct route, and the one to prefer once you hold it. The whole resolution step disappears — the single most expensive part of a job — and the answer cannot drift to a different hotel between runs. The id's format is checked at submit (digits only): a malformed id is rejected with 400 before any job is created or billed. A well-formed id from another OTA cannot be told apart and is priced as Agoda's own id — Agoda, MakeMyTrip and Goibibo ids are all plain numbers.

Checking we priced the hotel you meant. Read result.origin_hotel_name — what Agoda itself calls the property it priced. result.hotel_name cannot answer this on Agoda: it substitutes its own name rather than echoing your search text, but it's still not a confirmation signal — use origin_hotel_name. An empty origin_hotel_name means Agoda named nothing on that job, never that it agreed.

As of 18 September 2026, a by-name resolution takes a second look whenever the pick doesn't cover a distinguishing word from your request — typically a locality dropped because the name carries a chain suffix (e.g. ", an IHG Hotel"), which can make Agoda's own search substitute a same-brand property in another city instead of simply failing. This cuts down how often that happens; it isn't a guarantee, so keep checking origin_hotel_name regardless.

Device pricing — device_type

device_type is argument-driven: desktop (default) or mobile returns that device's actual room/rate matrix — not the cheapest price across devices. Ask for desktop and you get desktop prices even where mobile is cheaper, and vice versa. The device_type you submitted is echoed back on the job envelope.

desktop and mobile are both web identities — no OTA lets you ASK for Android apart from iOS on its website. Agoda's app_android value is different in kind: it selects a separate app route, below. Goibibo is the one source that always answers as the Android app internally, regardless of what you send.

The Android app route — device_type: app_android

A third device_type value, available for ota: agoda and ota: booking (see Booking.com's): it prices through the room-grid call Agoda's own Android app makes instead of its website, and returns the rooms and rates the app is quoted. It is not mobile renamed — the app's identity opens an app-only rate channel on a minority of properties (rate_channel_id "55"), where a phone browser is quoted a different fenced channel. MakeMyTrip, Expedia and Goibibo have no app route to select and reject app_android with a 400 naming device_type.

The result has the same envelope and response shape as every other Agoda job (see Response schema) — device_type is just echoed back as "app_android". Everything else on this page applies unchanged except the following:

Poll for results

Poll the poll_url every ~2 seconds until status is completed or failed. Statuses: pending → processing → completed | failed. Job IDs are scoped to this endpoint — a Google Hotels job ID 404s here, and vice versa.

Response schema

The poll response is a job envelope: id, status, ota, hotel_name, city, ota_hotel_id, place_id, check_in, check_out, adults, children_ages, rooms, currency, device_type, result, error_message, created_at, started_at, completed_at, duration_seconds, bandwidth_kb — plus tax_required / tax_scope, echoing what you submitted (see Taxes and fees). On completion, result holds the pricing object, which nests HotelRoomPricing → room_types[] → offers[]. (bandwidth_kb is the measured, compressed proxy traffic for the scrape — response headers excluded, and failed scrapes count what they spent.)

Object fields

Taxes and fees — the all-in for free, the split almost always free too

Two different questions, two fields:

fee_amount is deliberately net of its own tax — that tax is folded into tax_amount instead, which covers the whole charge, so the sum doesn't double the fee's tax. The sub-rupee gap against tax_and_fees is the published price being floored while the itemized figures are not.

tax_amount is null unless you ask for it. There's no estimate — a figure appears only where the rate was itemized for us, either for free straight off the room grid or on the booking form. Ask for it with:

"Cheapest" (what one_fare_per_room itemizes) means cheapest among rates that can seat your party — Agoda routinely returns rates that cannot, and as the cheapest row — falling back to the cheapest overall if none fit. tax_scope only bounds what a request may be spent on, not what comes back free — see below.

On a rate that was itemized you get three fields. tax_amount and fee_amount are always read rather than computed:

So the all-in is price + tax_amount + fee_amount. A real, measured example:

tax_basis comes free on every offer. On an itemized rate it's rewritten from what the itemization found: tax_and_fees whenever fee_amount is above zero, whatever the charge turned out to be. On a rate that was not itemized, it's read from Agoda's own extra-bed count alone — see the warning under the tax_basis field row above before treating tax_only there as "no charge at all".

tax_required without a tax_scope is not an error — it defaults to one_fare_per_room, the cheaper of the two.

Booking.com's default route and MakeMyTrip still report taxes and fees combined in tax_amount, from their own responses, with no split available via tax_required — see their guides. (MakeMyTrip does publish the free tax_basis now, so you can at least tell which rows carry a fee before deciding it doesn't matter. Booking.com's app_android route itemizes too, for free — see below.) Agoda, Expedia and Goibibo itemize — Goibibo's split costs nothing extra, unlike the other two.

An itemized offer in the result:

That rate carried an extra-bed charge, so it cost a booking-form request. Most rates don't need one — same request body, no extra cost, resolved straight off the room grid:

tax_percentage is populated there even though no booking-form request was made — the figure matched the GST slab (5% up to ₹7,500 a night, 18% above) on the rate's price exactly, which is how it was recognised as tax alone.

tax_required shipped 3 Sep 2026 to split a rate's tax from any extra charge beside it, itemized and verified per rate. The all-in figure it replaced was never wrong, only mislabeled — it's back as tax_and_fees, free on every offer whether or not you itemize, under a name that says what it actually contains. Changed 6 October 2026: itemizing stopped costing a request on almost every rate — see the Cost on Agoda callout above.

Children

Send ages, not a count: "children_ages": [9, 12]. Agoda prices each child by age — an 11-year-old and a 2-year-old are different products on the same rate — so there's no honest way to turn children: 2 into a request, and a bare children count is rejected with a 400 telling you to send ages.

When children are priced, occupancy on each offer counts all guests — Agoda's capacity line reads "2 adults & 2 children", reported here as 4 — so fits_occupancy keeps answering the same question it does for an adults-only party.

MakeMyTrip reports occupancy the same way — all guests folded into one number, when it can match the tariff on adults and children together. Expedia's occupancy was already a total-guest "Sleeps N" capacity before children existed, so it needed no change to fold children in the same way. Booking.com does not: it keeps occupancy as the adult capacity alone and states any child allowance separately, in a max_children field this endpoint returns only on Booking.com — because Booking itself sometimes reclassifies an older child as an adult, with no child line at all. See Booking.com's Children section for that mechanic.

Result outcomes

Submitting can 4xx (validation 400, auth 401, missing scope 403, throttling 429) or, rarely, a 5xx if we couldn't accept the job on our side — retry the submit. Once a job is accepted, polling always returns HTTP 200 — you distinguish scrape outcomes by fields, never by status code:

A scrape failure is never a 4xx/5xx on the poll — it is a failed job with an explanation.

Agoda-specific notes

• Resolved and fetched over pure HTTP.
• Channel fields (Agoda only): each offer carries supplier_id — an opaque id for who supplies the room; two offers differing only by supplier are different products, not duplicates — and rate_channel_id — an opaque id for the rate channel the offer was shown on. The result's suppliers[] / rate_channels[] roll up what the scrape was shown.
• Device identity (Agoda only): a phone and a desktop are quoted different prices for the same product on a minority of Agoda properties. On deployments where dual-identity fetching is turned on, an offer's device_identity reads "phone" or "desktop" (or null when only one identity answered) to say which device would have to be used to see that price again — the cheaper of the two arms wins per offer, matched by rate_token. This is an opt-in deployment setting, not a request field you can set; on any deployment where it's off, device_identity is always null.
• Payment timing (Agoda only): pay_later / payment_text read Agoda's own booking terms for the rate. It's a per-property behaviour, not a per-market one — some properties offer book-now-pay-later on every rate, most don't offer it on any.
• Delisted properties fail, they don't read as sold out: a stale/retired Agoda property_id answers as failed with error: "dead_property_id (property no longer listed on Agoda)", never as sold_out: true — the hotel may still be bookable on Agoda under a newer listing. Before failing, the job re-resolves from hotel_name + city (dead id excluded) and prices the current listing when one exists with a matching name, so a stale ota_hotel_id or place_id usually self-heals in the same job. This also covers Agoda's other two dead-id answers: "room-grid HTTP 500: No property data for id: <id>" and a bare no_rooms_returned (a genuinely full hotel answers sold_out: true instead). If it still fails, treat it as "no Agoda data for this hotel" and send hotel_name + city alongside the id — without them there is nothing to re-resolve from.
• A duplicate listing isn't trusted as sold out on its own: some properties are listed on Agoda more than once, and Agoda's own search can resolve to the copy that never has inventory. When the resolved listing comes back with no rooms and Agoda's search also offered the same property under another listing, that listing is checked too before the result is reported. If it also has no rooms, sold_out: true stands as a genuine result. If it exists but couldn't be reached, the job answers failed with error: "availability unverified: ..." instead of a false sold_out: true — treat this as retry-worthy, not as confirmed no-availability.
• Changed 15 September 2026 — cancellation state and meal plan on rates with no text. A rate inside its own penalty window carries no "Cancel for free …" wording at all; free_cancellation and refundable used to come back null there and are now read from Agoda's own cancellation flag and policy code — see the free_cancellation/refundable rows above. Room-only rates that name no meal are now EP instead of null, and a second meal listed as its own benefit beside breakfast is now MAP rather than CP — see the meal_plan_code row above.
• Changed 22 September 2026 — more meal wording recognised, and "All meals" corrected. The shared reader behind board (and, on Agoda, meal_plan_code) now also recognises trade rate-plan names that carry no meal word at all — "European Plan"/"Self catering" read as room only, "American Plan" as full board, "Modified American Plan" as half board — treats & as "and", and reads two meals named in either order ("Dinner bed & breakfast" is half board, not breakfast). Separately, a bare "All meals" now reads as full board rather than all inclusive: it names every meal and says nothing about drinks, which is the only thing separating the two — Agoda's own all-inclusive wording always adds them explicitly ("All meals + included beverages/extras"). If you stored a board or meal-plan history for Agoda, treat rows classified all-inclusive around this date as possibly full board instead.
• Changed 23 September 2026 — meal_plan_code also reads Agoda's benefit ids. See the meal_plan_code row above — a rate whose wording states no meal is now also read from Agoda's own numeric benefit ids, not just the isBreakfastIncluded flag. cheapest_fitting_meal_plan_code is new the same day — see the row above.
• Changed 30 September 2026 — tax itemization is free for most rates, and a missing fee line no longer blanks the rate. Two changes: (1) A rate with no extra bed (tax_basis: tax_only) now has tax_amount/fee_amount filled straight from the room grid's own tax_and_fees — no booking-form request (see the Taxes and fees cost callout above). A request is spent only on a rate that has one (tax_basis: tax_and_fees). tax_percentage was read from the booking form alone at that point, so it was null on every rate itemized the free way even though tax_amount was populated — superseded on 6 October (below): the recognised GST rate now fills it. (2) Separately, a bed-bearing rate whose booking-form breakdown carried no distinct fee line used to be refused outright (tax_amount: null) even though the form had already stated the tax; it's now accepted when the room grid's own combined figure corroborates the form's total, with the shortfall assigned to fee_amount — on that specific fallback path fee_amount can include the bed's own tax rather than being strictly net of it, unlike the ordinary case.
• Changed 30 September 2026 — every job now prices under Agoda's public rate channel. Previously, only tax_required jobs priced under the public channel (the booking form won't itemize a bed rate priced any other way); every other job priced under an affiliate channel by default. Every job is now on the public channel, so a tax_required job and an otherwise-identical job without it price the same hotel identically. On a sample of properties this also dropped some sponsored, campaign-only offers that never appear on Agoda's own public pages.
• Changed 6 October 2026 — itemizing is now free on almost every rate, fee_amount covers more than an extra bed, and a multi-room tax_and_fees bug is fixed. Three changes: (1) The 30 September shortcut keyed off tax_basis: tax_only (no extra bed), which trusted the room grid's combined figure to be tax and nothing else whenever there was no bed to explain it — true on 421 of 468 rates checked, but 47 carried an unflagged service charge or extra-person fee, so that shortcut has been replaced with one that proves a rate's figure is tax-only before trusting it: recognised on sight against the Indian GST slab, proven against a share already confirmed tax-only at the same property within 14 days, or confirmed by one booking-form request shared across every other rate at the same share. 97% of rates now resolve with no request at all, down from needing a request on every bed-bearing rate. (2) fee_amount is no longer only the extra-bed charge — it now also carries a service charge or extra-person fee where the booking form found one; tax_percentage can now come from the recognised GST rate as well as the booking form. See the fee_amount/tax_percentage/tax_basis rows above, and read the tax_basis warning before treating a non-itemized tax_only rate as charge-free. (3) tax_and_fees on a rooms > 1 job used to read the combined figure for every room, 136% of price at two rooms and 254% at three; it is now for one room, matching price — re-pull any stored multi-room history from before this date that used the field.
• Added 10 October 2026 — the app_android device route. device_type accepts a third value that prices through Agoda's Android app; see Android app route. Opt-in and switched off by default; the default (desktop / mobile) behaviour is unchanged.
• Added 13 October 2026 — tax_status. Every rate (on every OTA) and the result's cheapest_fitting_tax_status now carry included / excluded / unknown beside the boolean tax_included. A result stored before this date does not carry it.
• Added 14 October 2026 — rooms_booked and cheapest_room. A multi-room package ("2 X Room") used to be published as if it were one room, with the price of both; it now reports rooms_booked and never counts as fitting the party. cheapest_room is the new all-in cheapest rate described under Response schema.
• Changed 20 October 2026 — website-route jobs now come back tax-inclusive far more reliably. Agoda states a rate's tax-inclusive total to some device identifiers and not others. The default (desktop / mobile) route used to ask under a random identifier, so roughly half of jobs came back without the figure: tax_and_fees was null and cheapest_room.price_includes_taxes was false (pre-tax). It now asks under identifiers known to carry the figure, and re-asks under further ones before publishing an answer that lacks it. No request or response fields changed; a job whose retries all miss still reports tax_and_fees: null as before. Jobs scraped before this date may be pre-tax and can be re-pulled.

Next: Booking.com →