MakeMyTrip Flights

OTA flight pricing straight from MakeMyTrip's own site — the same job-based /scrape/ contract as Google Flights, with MakeMyTrip's own funnel layered on top: fare families, a price-lock premium, full review detail (baggage, cancellation, discounts and coupons) with on-request coupon pricing, the tiered price-lock options, and — the one stage that writes rather than quotes — a checkout that reaches the convenience fee, which nothing earlier in the funnel states.

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

Submit a search — L1

Omit return_date for a one-way search; include it for a round trip (see Round trips — MakeMyTrip prices these differently from Google Flights).

Poll for results

Poll every 1–2 seconds until status is completed or failed. The poll body is the full job record — keyed id (not job_id) — echoing your search parameters alongside status, result, error_message, error_category and timing fields. Same envelope shape as Google Flights.

The job record also carries leg, the funnel stage it ran: search for /scrape/ and /batch/, fare_families for /scrape/fares/, review for /scrape/review/ (including coupon pricing), farelock for /scrape/farelock/ and checkout for /scrape/checkout/. It is set at submit time, so a job that failed before answering still names its stage, and the jobs of one chain are distinguishable without inspecting result.

result.flights[] carries the same fields as Google Flights (price, currency, segments[], etc.) with these differences:

search_context.platform and search_metadata.platform echo which client (app or desktop) priced the job — present on every MakeMyTrip result, including failed ones, so provenance is readable from the job alone. See Platform.

Discounts & coupons — free with every listing

No flag, no extra request: every /scrape/ and /batch/ result on MakeMyTrip carries two kinds of coupon data, and they are not the same set.

All three counts at 0 together on a route that had them yesterday is worth checking — that's the signal that distinguishes "this route genuinely advertises nothing" from "the fields weren't populated".

Batch scraping

Search up to 20 routes that share dates/region in one call, the same /batch/ + /batch/results/ pair as Google Flights, with source: "makemytrip" at the batch level.

/batch/ and /batch/results/ behave exactly as described for Google Flights: 1–20 routes per batch, a shared set of dates and options, one request unit per route against the per-minute rate limit, and result records that may come back in any order and omit IDs you cannot read. Shared MakeMyTrip options: source, platform, include_price_lock.

Price lock — include_price_lock

MakeMyTrip sells an option to hold a fare for a while before committing — "Lock this price @ ₹179". That premium isn't part of the listing response: filling it in costs one extra request per search, so it's off by default. Set include_price_lock: true on /scrape/ or /batch/ to fetch it.

What this gives you is the teaser only: the single headline premium a traveller sees on the card. The tiered options behind the CTA — 12 hours / 1 day / 2 days / 4 days, each at its own price — come from a separate expansion, POST /scrape/farelock/; detail_api_path is passed through so you can see where MakeMyTrip keeps them.

Round trips — two different pricing shapes

Send return_date and both directions come back in one job — but MakeMyTrip prices a round trip two different ways, and which one you get depends on the route, not on anything you send. result.is_combo (top level, present on every completed and failed job — false rather than absent on the error path, so a caller never has to tell "not a combo" apart from "the job never got far enough to say") tells you which shape you're looking at. It's meaningful only for round trips: a one-way search (no return_date) has no return leg to pair a fare with, so is_combo is always false there too — check search_context.trip_type if you need to tell "one-way" apart from "round trip, not a combo".

Domestic — two independently priced legs

MakeMyTrip prices a domestic round trip as two separately selectable legs, each in its own list, each carrying its own fare:

cheapest_matching_price and cheapest_return_price are the cheapest fare left in flights[] and return_flights[] respectively, after the nearby-airport split and max_stops (applied to each direction independently). cheapest_round_trip_price is those two added together — a sum, not a quote — and is null unless both directions came back priced. There is no return-expansion endpoint here: unlike Google Flights' /scrape/return/, there's nothing to expand, since both directions are already in the response. Fare families and review accept a return_flight_index to price both legs of a round trip together — required on this shape, since which return leg to join is a real choice.

International — one card, one pair price (combo)

An international round trip is not two independently-priced flights. MakeMyTrip lists it as one card holding both journey keys at one combined price — the pair is the product, not a bundle of two separately-priced ones. Both halves still land in flights[] / return_flights[] as separate entries — a client already reading those lists needs no shape change — but each carries the same fare, flagged fare_is_pair: true, and no per-direction price exists to report:

cheapest_matching_price and cheapest_return_price are null here by design, not a gap — no outbound-only or return-only price exists on a combo listing, and reporting half the pair price as a one-way is exactly the misprice these fields exist to stop. cheapest_round_trip_price carries the real quoted total instead of a sum.

Fare families, review and checkout all treat a combo card the same way: the outbound card you pick (flight_index) has already chosen its return, so return_flight_index is not required on this shape — send it anyway and it's silently ignored, never a 400. This is the one behaviour that differs from the domestic shape, where naming the return leg is a real, required choice.

Platform — app vs desktop

MakeMyTrip has two clients behind this source, and they don't answer the same question equally well. platform picks one; it defaults to app, so a caller that never sends it keeps exactly the behaviour it already had. The makemytrip scope grants both — platform is a per-job argument, not a separate purchase.

Why choose desktop. It has fewer moving parts behind it, so it fails less often for reasons that have nothing to do with the route being priced. Why stay on app. Fare families, the review page, price lock, the price-lock tiers and checkout only exist there — if you plan to expand an itinerary past the initial listing, use app.

⚠️ Nearby-airport itineraries are split out

MakeMyTrip's listing mixes in itineraries that don't fly the requested route — e.g. a DEL→BOM search returning flights to Navi Mumbai (NMI) or from nearby airports. Measured live: 9 of 100 itineraries on that route. Left in flights[], a naive min(price) would hand you a price for a route the flight doesn't actually fly.

flights[] (and return_flights[], checked against the reversed route) therefore contains only itineraries matching the requested route. Itineraries on another airport pair are in nearby_airport_options[]; ones whose route couldn't be read are dropped and counted in search_context.unroutable_count, and ones removed by max_stops are counted in search_context.stops_filtered_out (max_stops is not applied to nearby_airport_options[]). search_context.route_honored is false when any were split out or had an unreadable route, or when the listing is empty, and cheapest_matching_price is the on-route cheapest fare.

Errors on this source

The error_category vocabulary is Google Flights' with two MakeMyTrip-only additions, fare_unavailable and pan_required (see checkout failures); the shared categories carry different meanings, and on this source they differ again by platform: transient means the request never got a usable answer (a dropped connection, a timeout, a 429 from MakeMyTrip that outlasted every attempt, a 5xx from MakeMyTrip's own servers, or our own time limit) — it is safe to resubmit a search, fare-families or review job, but not a checkout: a checkout that fails transient may already have held an itinerary, so check result.checkout first (see checkout failures). An app search, fare-families expansion or review that gets no usable answer is retried inside the job (up to 3 attempts), each from a fresh exit, before it reports transient, so a failing search can take longer than a successful one (the review that opens a checkout is the exception on 5xx: it is retried on a hang, a truncated body, a 403 or a 429, but a 5xx from MakeMyTrip is reported as transient without a retry); blocked means the request was refused at the edge — resubmit, it rotates exit IP; rotation means the wire format changed upstream (engineering fix, not retryable) — never an empty listing page, which is the empty result above; invalid_input covers requests rejected before sending; fare_unavailable means the flight or fare you picked from a search is no longer on sale — its rkey has expired (on the fare families (L2), review (L3) or checkout expansion), or MakeMyTrip answered 404 to one of those expansions — not retryable, run a new search and pick again; a search that MakeMyTrip answers with "no flights" is unchanged — a completed job with an empty result, as described below; invalid_search means MakeMyTrip's own origin read the request and refused it — not retried, since a fresh exit earns the same answer. On app that's an HTTP 400, and the one measured trigger is cabin_class: "first" on a domestic route — MakeMyTrip sells first class internationally only, and a domestic search carrying it fails this way rather than degrading to a lower cabin. On a search, a refusal page under a 400, or a bare 400, is also invalid_search — but never a 404: MakeMyTrip's 404 on a search means no flights, which is asked once more from a fresh exit and then returned as a completed job with an empty result, with or without a page in the body; on the fare families, review and checkout expansions a 404 is fare_unavailable instead (the request was fine, the fare is gone). /scrape/farelock/ is not covered by fare_unavailable. A search MakeMyTrip answers with "no flights" is confirmed once from a fresh exit and then returned as a completed job with an empty result, not as a failure. On desktop, MakeMyTrip instead answers with its own refusal envelope for the same kind of request (a bad route, a delisted sector) rather than an HTTP 400 — see also the first-cabin gotcha under Platform. POST /scrape/ still answers 202 for such a search either way (the API can't know a route is domestic, or delisted, before trying it); the job then fails on poll.

Fare families (L2)

Expand one MakeMyTrip itinerary into the fare families sold on it (e.g. SAVER / FLEXI / MMTSPECIAL, or airline tiers). MakeMyTrip only, and app platform only — this endpoint returns 400 for a Google Flights job, and the same 400 for a job that ran on platform: "desktop" (re-run the search with platform: "app" to expand it — see Platform).

• fare is per adult. journeyIndex is 0 for the outbound leg and 1 for the return, so one call returns both directions' families on a round trip.
• slashedFare is the struck-through price on that family, when MakeMyTrip advertises one — a display string (e.g. "₹ 6,593"), not a number, sent only when present. Unlike the L1 listing, this is populated on domestic routes too, so it can answer "what's the saving on this fare" where the listing's own discount reads null.
• The rkey is reissued: result.search_context.rkey in the response is a different key from the one the parent job produced — anything continuing the funnel must carry the reissued key, not the original.
• rkeys expire: a stale one returns no fare families and fails as error_category: "fare_unavailable" — deliberately not transient, since retrying can't help; re-run the search instead. Expand soon after searching.
• A domestic round trip requires return_flight_index — there's no server-side round-trip key, so the two legs' keys are joined and re-priced as a pair. Omitting it on a domestic round-trip parent is a 400. An international combo parent (is_combo: true) needs no return_flight_index at all — the chosen card already names its return leg. See Round trips.
• Guards shared by every expansion (/scrape/fares/, /scrape/review/, /scrape/farelock/, /scrape/checkout/): 403 without the makemytrip scope; 404 if job_id isn't yours; 400 if the parent isn't a MakeMyTrip job, ran on platform: "desktop", isn't completed, the chosen flight has no booking_token, or the chosen row is from a sequential-layout round trip (no named return flight; re-run the search and expand a row from the new result). An out-of-range index is 400 {"flight_index": "index N out of range (M in `flights`)."} (return_flight_index checks against return_flights). The expansion repeats the parent's passengers, cabin, region and currency, so there is nothing to resend.

Coupons on the fare sheet — offers[]

No flag, no extra request: every fare-families result also carries the coupon strip MakeMyTrip draws under the fare cards (e.g. "Get Flat 12% OFF using MMTHSBC code"), in the same four keys as the L1 listing's flights[].offers[] — code, amount, percent, text.

Review (L3, read-only)

Expand one MakeMyTrip itinerary into its review page — the richest response in the funnel: the fare split into base and tax with the line items behind it, the baggage allowance per leg and passenger type, the cancellation and date-change rules, and the coupon tray as advertised. MakeMyTrip only, and app platform only — this endpoint returns 400 for a Google Flights job, and the same 400 for a job that ran on platform: "desktop" — see Platform. Same request shape as fare families (L2) — a completed search plus which itinerary — and the same 202-then-poll flow; the two expansions are independent, both keyed off the original L1 search job.

Same guards and rkey rules as fare families: parent must be a completed MakeMyTrip job, return_flight_index is required on a domestic round-trip parent (not on an international combo one — see Round trips), and a stale key fails as error_category: "fare_unavailable" rather than transient — re-run the search instead of retrying. Unlike fare families, the review response does not reissue a new rkey; it's the last stop in the read-only part of the funnel.

Coupon pricing — price_coupons

Add price_coupons: true to a /scrape/review/ request and, instead of just listing the advertised tray, each coupon is actually applied to the live itinerary and read back priced. This is a different list from the two the search already gave you (see Discounts & coupons) — the search advertises, this is the only thing on this API that prices.

Sending price_coupons: true to /scrape/checkout/ is rejected with 400 rather than silently ignored — a checkout's itinerary is the one being held, and pricing coupons down it the way review does could alter that cart irreversibly. Use include_coupon_breakups there instead: it prices the tray on a disposable itinerary and never touches the held one.

Choosing a fare — fare_index

By default every expansion prices the cheapest fare on the itinerary you pick. Add fare_index to ask for another one — it needs nothing extra from the search.

Measured live on DEL→DXB (29 Oct 2026), one journey, only fare_index changing:

fare_index works on /scrape/review/, /scrape/farelock/ and /scrape/checkout/, so the convenience fee can be read per fare. search_context.fare_index echoes what you asked for.

• Listing prices are index 0. A row's price is the default fare; for any other fare only the review's total is authoritative.
• One-way, MakeMyTrip only. fare_index is 400 on a round-trip parent (expand each leg as a one-way search instead) and 400 on /scrape/fares/.

Price-lock tiers — POST /scrape/farelock/

The price-lock teaser on a listing card is one headline premium. This expansion returns the tiered options behind it for one itinerary — what it costs to hold the fare for 12 hours, 1 day, 2 days or 4 days, each at its own price. MakeMyTrip only, and app platform only — 400 for a Google Flights job and for a platform: "desktop" parent, like the other expansions. Read-only: it reads the advertised tiers and selects nothing.

Checkout — POST /scrape/checkout/ ⚠️ writes

Every other endpoint on this source quotes. This one holds inventory. It runs the itinerary through MakeMyTrip's own checkout chain to a live checkoutId and reads the resulting payment page — the only place the convenience fee and the true final total appear. Every other total in this funnel, including the review, excludes that fee. app platform only — 400 for a platform: "desktop" parent job, same as fare families and review — see Platform.

Same request shape as fare families / review — a completed MakeMyTrip search job, flight_index, and (round trips, domestic only — see Round trips) return_flight_index — plus one flag of its own:

Coupon breakups — include_coupon_breakups

Add include_coupon_breakups: true and the result gains coupon_breakups: the cart with no coupon, plus the three coupons that actually save the most, each with its own fully repriced breakup. This is the checkout's equivalent of price_coupons on review — deliberately a separate flag, because it works differently under the hood.

What comes back on failure

The chain is not atomic. A partial run is reported, not discarded — if a checkoutId was issued before a later step failed, it's in result.checkout; a checkoutId that exists and isn't returned would be an abandoned booking nobody could trace.

The one call retried inside a checkout is the review that opens the chain, because it only reads: a hang, a truncated body, a 403 or a 429 is asked again from a fresh exit, up to three attempts in all. A 400, a 404, a 5xx or a stale key is not retried, and nothing after the review ever is.

Next: Google Hotels →