Booking.com

Return the exact per-room-type price a real guest sees on Booking.com'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:booking scope · See the Overview.

Submit a job

Identifying the hotel

A request identifies its hotel one of three ways.

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

The city you send is checked against Booking's own label for the property's town with accents folded ("Mūvattupula" reads as "Muvattupula") and a few common aliases (Alleppey / Alappuzha). Where Booking's search labels the town with a different transliteration than yours — "Muvattupuzha" against Booking's "Mūvattupula, Kerala" — the candidate is checked against the town in Booking's own record of the property before it is refused, so a correct spelling of the city no longer fails the job. A candidate whose record places it in another city is still refused.

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 Booking'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 Booking 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 Booking's own id (ota_hotel_id) 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.

Checking we priced the hotel you meant. Read result.origin_hotel_name — what Booking itself calls the property it priced (its own page title). result.hotel_name cannot answer this: it's your own search text echoed back, not confirmation that Booking agreed — use origin_hotel_name. An empty origin_hotel_name means Booking named nothing on that job, never that it agreed.

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. Goibibo is the one source that always answers as the Android app internally, regardless of what you send. The app_android value (Booking.com and Agoda) doesn't select a web device at all — it selects a separate app route, below.

The Android app route — device_type: app_android

A third device_type value, available for ota: booking and ota: agoda (see Agoda's app route, which behaves differently): it prices through Booking's own Android app API instead of its website, and returns the rooms and rates the app itself is quoted — not another web device, a different route entirely. Any other OTA rejects app_android with a 400 naming device_type (MakeMyTrip has none; Expedia and Goibibo are already app routes with no web route alongside them to pick from).

The result has the same envelope and response shape as every other Booking.com job (see Response schema above) — device_type is just echoed back as "app_android". These fields behave differently on this route:

Taxes on the app route — free, like Goibibo

tax_required is rejected with 400 on Booking.com's default route — its hotel document has no components to itemize — but it is accepted, at no extra request, on device_type: app_android: the app's own room list states every charge it adds on top of the price, the same way Goibibo's does.

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, tax_required, tax_scope, rooms, currency, device_type, result, error_message, created_at, started_at, completed_at, duration_seconds, bandwidth_kb — tax_required / tax_scope echo what you submitted (false / "" when you sent neither). 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

Children

Send ages, not a count: "children_ages": [2, 8]. Booking.com prices each child by age — its own hotel-page URL carries an age/req_age pair per child — so a bare children count is rejected with 400, same as on every other OTA.

Some childful searches show each rate as "Guests: 2 adults , 1 child" with no "Max children" line at all. That line is read as the party the rate was priced for: occupancy_source is "priced", occupancy is the adults and max_children is the children — so such a rate seats exactly that party (and not 3 adults, or 2 adults with 2 children). Before October 2026 those rows were read as having no child allowance, so a childful search could come back with no rate fitting the party.

Contrast with Agoda and MakeMyTrip, where a matched childful rate reports occupancy as all guests (adults plus children) with max_children always null — that field only ever appears on Booking.com results.

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.

Booking.com-specific notes

• Discounted rates: Booking.com renders a discounted row as two amounts — the struck-through original and the amount actually payable. price / price_text are always the payable amount; price_before_discount carries the struck-through original on those rows and is null otherwise. A public promotional discount is reported this way, but Booking.com rendered no strikethrough in our captures on this route, so price_before_discount is null in practice today.
• Stale identifiers fail, they don't read as sold out: Booking answers a hotel URL it no longer recognises with the city search page rather than a 404, which has no room grid. That is detected and reported as failed with error: "wrong_slug (hotel page redirected to search results)", never as sold_out: true — treat it as "no Booking data for this hotel" (the same bucket as Agoda's dead_property_id) rather than genuine no-availability. The stale identifier is retired automatically and the next request re-resolves live, so an immediate retry is unlikely to help but a later one will.
• Download stops early: where enabled, the default route stops downloading the hotel page once the rooms have arrived — the result is field-for-field what the whole page would have given, but bandwidth_kb counts only the bytes taken before the stop. Not applied to the app_android route, which has no page.
• source is "http" on every Booking.com result, on both routes.

Next: MakeMyTrip →