Expedia

Return the exact per-room-type price a real guest sees on Expedia — resolved via Expedia's own mobile app API, 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:expedia scope · See the Overview.

Submit a job

Identifying the hotel

A request identifies its hotel one of two ways on Expedia — there's no third, id-only route the way there is on the other OTAs, because Expedia needs a hotel and a region to address a property.

By name (hotel_name + city) is the default: resolved fresh through Expedia's own typeahead search on every request, to a hotel-and-region pair.

By Google Place ID (place_id) is the recommended way to pin a portfolio, as on Agoda, Booking.com, MakeMyTrip and Goibibo. The first request for a place still goes through Expedia's typeahead (on your hotel_name and city if you sent them, otherwise on the identity we hold for the Place ID); the hotel and region that actually returned a price are then pinned together, so every later request for that place_id addresses the same property directly and skips the search. A property is pinned only when Expedia names it and its name agrees with the Place ID's own; a pin that Expedia stops listing fails the job as dead_property_id and is retired, so the next request resolves afresh.

Device pricing — device_type

device_type is argument-driven on Agoda and Booking.com, and accepted (but ignored) on MakeMyTrip and here. The field is still validated — desktop or mobile; app_android (the route Agoda and Booking.com offer) and anything else 400 — and echoed back on the job envelope, but it has no effect on which prices you get.

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[] — the same shape as every other OTA on this endpoint. (device_type is always echoed but carries no meaning on Expedia — see Device pricing; ota_hotel_id is always "" here — a submitted one is rejected outright, see Identifying the hotel; 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

tax_amount is null unless you ask for it — and unlike Agoda, there's no free combined figure to fall back on. Expedia's offers response carries no tax-bearing field at all (every one of mandatoryFees, fees, price.total.amount and the rest comes back empty on this route); the amount only exists at Expedia's own checkout, which this source visits only when you opt in:

Both scopes run four rates at a time to keep wall-clock down without raising the request count — measured on a 20-rate property, 24.9 s against 63 s serially. On a rate that was itemized you get three fields, all read from Expedia's own checkout page rather than computed, and rebased onto price's own per-night/whole-stay period so price + tax_amount + fee_amount is a consistent all-in:

tax_percentage and tax_and_fees stay null on Expedia either way — its checkout page states amounts, not a rate, and there is no free all-in figure the way Agoda's rate token gives one.

A real, measured example — same property as the Children section, 2 nights:

Itemizing never costs extra quota: a job is one unit whatever tax_required says; the checkout requests show up in bandwidth_kb. tax_required without a tax_scope is not an error — it defaults to one_fare_per_room, the cheaper of the two. tax_required on an OTA that can't itemize (only Agoda, Expedia and Goibibo do, today) is a 400 — see Agoda's guide for that error's exact wording.

An itemized offer in the result:

Children

Send ages, not a count: "children_ages": [4, 15]. Expedia's own app schema (rooms[].children: [{"age": n}]) prices each child individually — a 4-year-old and a 15-year-old move the same room by different amounts — so, same as every other OTA on this endpoint, a bare children count is rejected with a 400 telling you to send ages.

With more than one room, ages are dealt round-robin into the room list — [4, 7, 9] over 2 rooms becomes [[4, 9], [7]], spreading the party the same way adults already does — and never duplicated: unlike adults (rounded up and repeated per room), copying an age would invent a child that does not exist.

occupancy stays what it always was on Expedia — the room's stated "Sleeps N" capacity, not the specific party priced (see the Response schema table) — but fits_occupancy now checks it as a total guest count: a 3-person party (2 adults + 1 child) qualifies on a Sleeps-4 room and is refused on a Sleeps-2 one. Expedia states no separate child allowance the way Booking.com's max_children does — see Booking.com's Children section for that mechanic — so a child here is simply one more of the "N" guests the room sleeps.

Occupancy from the rate itself

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.

Expedia-specific notes

• Resolved and fetched over the mobile app's API, not the website. Expedia's website is behind a heavier anti-bot wall than the other three OTAs; this source instead speaks the same GraphQL API the official Expedia Android app calls, which is why every scrape carries a mobile-app identity — see Device pricing above.
• Currency picks the storefront. Unlike Agoda/Booking.com (a single storefront priced in whichever currency you ask for), Expedia prices natively per point-of-sale: INR → expedia.co.in, USD → expedia.com, GBP → expedia.co.uk, AED → expedia.ae, SGD → expedia.com.sg. INR is the default, the most-tested storefront, and the reason this source exists — it sidesteps a currency-conversion problem the other storefronts don't need to solve for Indian bookings. There is no EUR storefront.
• Room content is enriched: each room type carries bed, canonical dual-unit room_size / room_size_sqm, up to 8 images, a detailed amenities list (Agoda-parity — hair dryer, minibar, desk, …), and a stated max_guests capacity; each offer carries a board (meal plan) and a per-rate cancellation_text / refundable reading — all parsed straight from the app's own room content.
• Occupancy: like the other three OTAs, adults is a party total divided across rooms (one room entry per room), and every offer's price is for one room. Read cheapest_fitting_price rather than taking your own minimum over offers[] — the same "cheapest row often can't seat the party" trap applies here too.
• Pinned by Place ID, since 12 October 2026. place_id now pins Expedia's hotel-and-region pair like every other OTA; a repeat request skips the typeahead. Every Expedia job also asks Expedia for its own name for the property, which is what fills origin_hotel_name and tells a delisted id apart from a genuine sold-out.

Next: Goibibo →