MakeMyTrip (Hotels)

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

For India-specific pitfalls — GST threshold, number formatting, point of sale — see India hotel price data.

Base URL: https://api.scrapeguys.com · Auth: X-API-Key: gsk_… with the ota:makemytrip 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 MakeMyTrip's own autosuggest and picked by us. It works without you knowing anything about MakeMyTrip, and is what every existing integration uses. It is also the only one of the three routes that can return the wrong hotel: MMT's own autosuggest has known failure modes and can match a same-named property in the wrong place. Since 16 October 2026 the matcher cleans spreadsheet-style names (trailing | City tags, descriptive brackets, chain prefixes), retries with the city added to the query when the name alone gives no acceptable pick, and checks every pick against the property's location and the city you sent — a candidate in another country or far from the city is refused, and unconfirmed matches are never cached. This makes a wrong match much rarer, not impossible. A property more than about 50 km from the city you named may be refused as unresolved; send the city the property is actually in. Prefer place_id or ota_hotel_id wherever you can.

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 MakeMyTrip's own autosuggest — 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 MakeMyTrip 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 MakeMyTrip's own id (ota_hotel_id, its numeric hotelId, e.g. "201709071828297454") is the fastest and most direct route, and the one to prefer once you hold it. The whole resolution step disappears — roughly 2.0s of a ~2.9s MakeMyTrip job, the single most expensive step — and, unlike the name route, 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 MakeMyTrip'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 MakeMyTrip itself calls the property it priced, sourced from the hotelName parameter of the deeplink MakeMyTrip's own site builds. That makes it a genuine statement from MakeMyTrip, not an echo of your text: when a job is submitted with ota_hotel_id, we send MakeMyTrip nothing but a hotel id, so any name in that deeplink is MMT's own. result.hotel_name cannot answer this question at all — it is your own search text echoed back, not a confirmation signal. An empty origin_hotel_name means either MakeMyTrip named nothing on that job, or you identified the hotel by ota_hotel_id and no name search ran, so there's nothing to echo unless MakeMyTrip's own response states a name — never that it agreed with you.

Device pricing — device_type

device_type is argument-driven across this API: desktop (default) or mobile. The field is accepted and 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. A separate app_android route exists for Agoda and Booking.com only. Goibibo is the one source that always answers as the Android app internally, regardless of what you send.

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; tax_required itself is rejected on this OTA). 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": [4, 7]. MakeMyTrip prices each child by age on the same roomStayCandidates[].childAges field its own site sends, and echoes the ages back onto the matching tariff — so a bare children count is rejected with 400, same as on every other OTA.

When MakeMyTrip can match a tariff on adults and children together, occupancy on that offer counts all guests — a match on 2 adults + 2 children reports occupancy: 4 — the same convention Agoda uses, and unlike Booking.com, which keeps a separate max_children field instead (always null here). Measured live, same hotel/room/dates: 2 adults, no children → ₹6,000; 2 adults + children aged [4, 7] → ₹7,000 — a real price difference, not just an accepted request, and it agrees with the rate plan's own FREE_CHILD inclusion line: the 4-year-old adds nothing, the 7-year-old adds exactly ₹1,000.

When no single room type matches the party. Most multi-room searches — and a childful one the property re-splits — get no per-room-type answer from MakeMyTrip at all, only recommended bundles: whole bookings, each a set of rooms with one price for all of them. Since 14 October 2026 those are read instead of failing the job with no rooms: each bundle becomes one offer at its per-room share (the bundle price over rooms, through the same discount and tax handling as an ordinary rate), on a room type named for the rooms in it (e.g. "King Smoking + King Non-Smoking"). MakeMyTrip splits a party however it likes — 1 + 3 adults across two rooms — so a bundle is never read room by room.

Result outcomes

Submitting can 4xx (validation 400 — including a check-in more than 364 days ahead and a misspelt field name, 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.

MakeMyTrip-specific notes

• Currency: INR only — other codes are rejected rather than mislabeled.
• Price basis: always per_night_before_taxes — a fixed basis shared with Goibibo only; every other OTA here derives it per offer.
• Distinguishes genuine no-availability (returns sold_out: true) from property errors, unlike a generic failure.
• Amenities: amenities returns MakeMyTrip's own real facility names for the room (e.g. "Wi-Fi", "Minibar"), in MakeMyTrip's own display order, deduped and capped at 8 — not a fixed set of category headings.

Next: Expedia →