Flight data.
Without a partner agreement.

A REST endpoint and MCP tool that returns flight data as structured JSON. You send an origin, a destination and a date with a Bearer token; you get back priced itineraries for that route — the operating carrier, how many stops, where it stops and for how long, departure and arrival times, and the total. One-way or round trip, in the cabin and currency you ask for. No airline account, no partner agreement, no HTML to parse.

As many as the route has. A measured JFK→LHR search on a single October date returned 48 priced itineraries in one call; DUB→STN returned 18; a LAX→NRT round trip for two adults returned 18. Every one of them was priced. There is no paging to walk and no second call to make — one request is the whole answer for that route and date.

Both ends of the market, side by side in the same response. A measured Dublin to London Stansted search returned Ryanair and Ryanair UK alongside Turkish Airlines — a budget carrier and a flag carrier ranked together on price. A measured Los Angeles to Tokyo search returned United, JAL, ANA and Philippine Airlines. You are not getting one alliance or one booking channel.

Both, and you should read the count rather than infer it. Every itinerary carries stops as a number and layovers as a list, each entry naming the airport code, the airport's full name, the city and how long the wait is in minutes. A measured Los Angeles to Tokyo option came back with one stop and a 125-minute layover at Manila. Note that a one-stop itinerary can arrive described as a single leg, so counting legs would call it a nonstop — stops is the field that is always right.

Yes — add a return date and the price covers the whole trip, flagged as round_trip_total so you never mistake it for a one-way fare. One thing to know: each outbound option is priced against its cheapest matching return, and that return flight is not itemised, so the response describes the outbound leg and not the inbound one. The total is real; the return leg's times are not in the response. Leave the return date off and you get a straightforward one-way search — there is no implicit return window.

Both. Set nonstopOnly and connections are excluded outright. Set cabinClass to any of economy, premium_economy, business, first and results are priced for that cabin — a measured JFK→LHR business-class search returned 44 priced itineraries, against 48 in economy. You can also price for a whole family in one call: up to 9 adults, plus children and infants counted separately.

Whichever you ask for. Pass a three-letter currency code and every price comes back in it, as {amount, currency, formatted} — a number you can sum, the code beside it, and a display string. Omit it and results come back in the service's own default, reported on the response so you always know which one you are looking at.

Every response carries scrapedAt, an ISO timestamp for when the fares were read. Airfares move constantly and any figure you hold is a snapshot — so the response tells you when the snapshot was taken rather than leaving you to assume it matches the time you happened to look. Use that timestamp, not a cached one.

You get a 200 with an empty list and a note saying so in plain words: "No itineraries were found for these dates and filters." A route with nothing available is a real answer, not a failure — so there is nothing to retry and nothing to mistake for an outage. A measured search for a first-class nonstop on a short-haul budget route returned exactly that.

You get a 400 that names the problem. A malformed airport code returns {"error":"origin: must be a 3-letter airport code"}; a departure date in the past returns {"error":"departureDate \"2020-01-01\" is in the past"}; a field the route does not know returns {"error":"Unrecognized key: \"sortBy\""} rather than being silently ignored. Wrong requests fail loudly and immediately instead of costing you a call and returning something odd.

Measured against production on 17 September 2026, three runs each: JFK→LHR answered in 1.3 to 2.8 seconds with 48 itineraries, DUB→STN in 1.7 to 1.9 seconds, a LAX→NRT round trip for two adults in 1.7 to 2.8 seconds, and a filtered nonstop business-class search in 1.8 seconds. One request, one answer, no paging.

One credit per search, reported on every response as pagesFetched. A search costs the same whether it returns 48 itineraries or none, and there is no pagination to multiply it — the whole result set for a route and date is a single request.

Yes. The route is an MCP tool on the same FetchLayer MCP server: flights_search. Tool calls use the same key and are billed exactly like REST, and the agent sees the priceType and the scrapedAt timestamp alongside every fare — so it can tell you that a figure is a round-trip total read four minutes ago, rather than presenting it as a one-way fare that is true now.