Qatar Airways Flight Scraper — Dated Lowest Fares & Live Flight Status

Fare coverage note (September 2026)

Qatar Airways moved per-flight cash fares (POST /flight-search/flight-offers) behind Akamai Bot Manager: it now needs a device-bound X-acf-sensor-data sensor token and returns

403 Access Denied

to any headless client (on every proxy type and TLS fingerprint). So schedules mode now returns Qatar's dated lowest-fare calendar — real economy fares from the same API, one row per day — instead of per-flight cash fares. flightStatus mode is unaffected. If Qatar drops the sensor requirement, per-flight fares resume automatically with no change.

Qatar Airways Flight Scraper reads Qatar Airways' own mobile API directly, so it's fast, reliable and complete — no flaky HTML parsing, no headless browser. Read-only public travel data. Export to JSON, CSV, Excel, or an API.

What can it scrape? (two modes)

schedules (default) — Qatar Airways' dated lowest-fare calendar (economy) for a route around your date: one record per day with the lowest available fare and any promo discount. The calendar is returned by default. (Per-flight cash fares with fare families are attempted too, but Qatar now serves that specific endpoint behind Akamai Bot Manager — see Good to know — so it is best-effort and usually returns nothing; the lowest-fare calendar is the reliable fare signal.)

flightStatus — live operational status, one record per flight: arrived / on-time / delayed, aircraft type, and scheduled, estimated and actual departure/arrival times. Set origin + destination + departureDate for every flight on a route/date, or set flightNumber (e.g. QR11) to track a single flight. An empty date means today.

// dated lowest fares DOH -> LHR (calendar is on by default)
{ "origin": "DOH", "destination": "LHR" }

// live status of every DOH -> LHR flight today
{ "mode": "flightStatus", "origin": "DOH", "destination": "LHR" }

// one specific flight
{ "mode": "flightStatus", "flightNumber": "QR11" }

Every row — flight, calendar and status — shares one flat schema, so a mixed export stays a single table; fields that don't apply to a row type are null.

What timezone are the times in?

Times keep their original UTC offsets (e.g. 2026-10-06T01:10:00+03:00), so local times are unambiguous and no timezone is assumed on your behalf.

What inputs does it take?

Field	Type	Default	Description
mode	string	schedules	schedules = dated lowest-fare calendar (economy). flightStatus = live status for a route/date or one flight.
origin	string	DOH	Origin airport IATA code.
destination	string	LHR	Destination airport IATA code.
departureDate	string	–	Date, or a relative value like "30 days". Schedules: empty = +30 days. Status: empty = today.
returnDate	string	–	Schedules only. Set for a round trip. Empty = one way.
adults	integer	1	Number of adult passengers.
currency	string	USD	3-letter currency code for fares.
includeCalendar	boolean	true	Schedules only. Emit one record per date from the lowest-fare calendar (the reliable fare signal). Set false to skip it.
flightNumber	string	–	Flight-status only. One flight, e.g. QR11. Empty = every flight on the route/date.
maxItems	integer	100	0 = all results.
proxyConfiguration	object	RESIDENTIAL	The Akamai edge blocks datacenter IPs; a residential proxy is set by default.

What does each row contain?

Every row is flat and carries the same keys, with type saying which kind it is and the inapplicable fields set to null.

On every row

Field	Description
type	calendar, status or flight
origin / destination	IATA codes for the row's route
departure_date	The date the search or status lookup was for (YYYY-MM-DD)
currency	Currency of the prices on the row

type: "calendar" — one row per date from the dated lowest-fare calendar:

Field	Description
calendar_date	The date this lowest fare is for
calendar_lowest_price	Lowest available economy fare for that date, as a number
calendar_discount_code	Promo/discount code Qatar applied to that date, when there is one

type: "status" — one row per flight from the flight-status feed:

Field	Description
flight_numbers	Single-element array with the marketing flight number, e.g. ["QR11"]
operating_airline	Carrier code, normally QR
aircraft	Equipment code for the aircraft type
status	Qatar's flight status, e.g. on time, departed, arrived, delayed
status_detail	Qatar's operational status code behind that status
scheduled_departure / estimated_departure / actual_departure	Timestamps with their original UTC offsets
scheduled_arrival / estimated_arrival / actual_arrival	Same, for the arrival

type: "flight" — one row per per-flight cash offer. Read the coverage note above first: this row type only appears if Qatar's fare-offers endpoint answers, which it currently does not.

Field	Description
flight_numbers	Every flight number in the itinerary, in order
operating_airline	Operating airline name for the first segment
aircraft	Aircraft name for the first segment
departure_time / arrival_time	Itinerary start and end, with UTC offsets
duration_minutes	Total itinerary duration in minutes
stops	Number of stops
cabin	Always ECONOMY — see Good to know
fare_family	Fare family code of the cheapest priced offer
price_base / price_total	Base fare and total for that cheapest offer
available_seats	Seats left at that fare, as Qatar reports it
fare_offers	Array of every fare family with its total and availableSeats

Which routes and currencies can I use?

Any route Qatar Airways operates. The actor passes the IATA codes you give it straight to Qatar's own API and keeps no route list of its own, so a pair Qatar does not fly simply returns zero rows with a warning in the log rather than an error. Everything is via the Doha hub (DOH):

Region	Example airport codes
Hub	DOH Doha
Europe	LHR London Heathrow, CDG Paris, FRA Frankfurt, MAD Madrid, MXP Milan, IST Istanbul
North America	JFK New York, ORD Chicago, LAX Los Angeles, IAD Washington, YYZ Toronto
Middle East & Africa	DXB Dubai, RUH Riyadh, CAI Cairo, JNB Johannesburg, CPT Cape Town, NBO Nairobi
South Asia	DEL Delhi, BOM Mumbai, BLR Bengaluru, CMB Colombo, KHI Karachi
East Asia & Pacific	SIN Singapore, BKK Bangkok, HKG Hong Kong, NRT Tokyo, SYD Sydney, MEL Melbourne

Fares can be requested in any of these ten currencies: USD, GBP, EUR, QAR, AED, INR, AUD, CAD, SGD, CHF.

What do the fare and status terms mean?

• Dated lowest-fare calendar — Qatar's own "cheapest fare per day" view around your date. One row per date, each holding the lowest economy fare available that day for the route. It answers "when is this route cheapest", not "which flight costs what".
• Per-flight cash fare — the price of one specific itinerary, with each fare family priced separately. This is the type: "flight" row, and the endpoint behind it is currently sensor-walled (see the note at the top).
• Fare family — Qatar's branded economy fare tiers, returned as the code Qatar uses (fare_family, and one entry per family in fare_offers). The actor reports the code verbatim rather than inventing a label for it.
• price_base vs price_total — base fare before taxes, fees and surcharges, and the all-in total for the same offer. Compare totals, not bases, across airlines.
• Scheduled / estimated / actual — the published time, Qatar's current forecast, and what actually happened. A flight that has not departed has no actual_departure; a delay shows up as an estimated_* time later than the scheduled_* one.
• IATA code — the 3-letter airport code (DOH, LHR). The actor requires it in that form and rejects anything else with a clear message instead of guessing.

Good to know

• Economy only. Qatar's mobile fare API serves economy on this channel; Business/First return a gateway error and are not offered rather than shipped as an option that fails.
• Cash per-flight fares are behind Akamai Bot Manager. As of app v26.10.x, Qatar's mobile fare-offers endpoint requires a device-bound X-acf-sensor-data sensor token and returns HTTP 403 "Access Denied" to any client without it (on every residential/mobile exit and TLS fingerprint) — so per-flight cash fares and fare families are not available headlessly. The actor returns the dated lowest-fare calendar instead (real economy fares, still from Qatar's own API), and flight status is unaffected. If Qatar removes the sensor requirement, per-flight fares resume automatically with no change.
• No login, no booking, no PNR lookup — read-only public search, exactly what the app shows a signed-out user. There is no request signing, API key or OAuth on this surface.
• Fare availability and prices are point-in-time and market/currency-scoped.

How much does it cost?

Pay per event: $2.00 per 1,000 records. One charge per row delivered, whether it is a calendar date, a status row or a flight offer — nothing is charged for a request that returned no rows.

maxItems bounds the run (default 100, 0 = everything the API returns). A 30-date calendar snapshot is 30 rows, or $0.06; a day of flight status on one route is a handful of rows.

FAQ

Do I need a Qatar Airways account, a Privilege Club login or an API key?

No. This is the read-only public surface the app shows a signed-out user. There is no API key, no OAuth and no request signing — only a client-generated session id and device id, which the actor generates itself. No booking and no PNR lookup either.

Can I get business or first class fares?

No, economy only, and that is deliberate. Qatar's mobile fare channel answers BUSINESS and FIRST with a gateway error, so the actor does not offer a cabin selector it cannot honour.

Can I track one specific flight?

Yes. In flightStatus mode set flightNumber to QR11 or just 11 and you get that flight for the date you asked for; leave it empty and you get every Qatar Airways flight on the route that day. An empty date means today.

Can I price a round trip?

Yes — set returnDate in schedules mode and the search is priced as a return itinerary. The rows still describe the outbound route and its dates, so treat returnDate as part of the pricing request rather than a second set of rows.

What proxy should I use?

Leave the default. Qatar's Akamai edge blocks datacenter IPs, so Apify Proxy with the RESIDENTIAL group is pre-set. On a failure the actor retries from a fresh exit IP and cycles the exit country (GB, DE, US, NL, FR, QA, IN) because some exits get a spurious error from the fare backend; if you pin your own country in the proxy config, it leaves your choice alone.

Can I run it on a schedule?

Yes, and it is the main reason to use it — a daily run of the fare calendar on your route builds a price history no single search can give you. The actor keeps no memory between runs, so de-duplicate on calendar_date (or flight number and date) if you append runs to your own store.

What happens if there are no flights, or I mistype a code?

A route or date with nothing on it finishes successfully with zero rows and a warning in the log, so an empty dataset is never mistaken for a crash. An airport code that is not three letters fails the run immediately with a message naming the offending value.