AIRLINE FARE DATA API
From an airline website.
Into your data model.
Farelint collects fare observations for a specified airline and trip, then returns structured JSON with capture time, passenger context, price basis and missing fields. Built for travel software and analysis through an HTTP API or MCP.
What does the API return?
A request names one airline, airports, travel dates, passengers, cabin and requested currency. Accepted work returns a durable job. Poll it or use completion webhooks, then inspect the observations and collection outcome.
- Trip context: the requested trip and effective values that could be verified.
- Price context: original currency, per-adult or party basis, quote type and whether a total was observed or derived.
- Collection context: capture time, complete/partial/failed status, source and coverage scope.
- Explicit unknowns: missing baggage, full fare rules or an unverified market remain unknown.
A price without the guesswork.
This is an excerpt from an illustrative contract fixture, with a fixture timestamp of 29 October 2026. It demonstrates the data shape; it is not a current quote or proof of live availability. The complete result nests each price inside its itinerary.
{
"schema_version": "1",
"airline": "aegean",
"observed_at": "2026-10-29T20:00:00Z",
"request": {
"airline": "aegean",
"origin": "LCA",
"destination": "ATH",
"departure_date": "2026-11-21",
"return_date": null,
"passengers": {
"adults": 1,
"children": [],
"infants": []
},
"cabin": "economy",
"market": "GB",
"language": "en",
"currency": "EUR"
},
"effective_request": {
"market": null
},
"itineraries": [
{
"flight_numbers": [
"A3909"
],
"price": {
"amount": "62.38",
"currency": "EUR",
"kind": "cabin_starting_quote",
"basis": "per_adult",
"quantity": 1,
"party_total": "62.38",
"total_method": "derived",
"net": null,
"taxes": null,
"extras_included": false,
"checkout_verified": false
},
"missing_fields": [
"segments.utc_times",
"baggage",
"full_fare_rules"
]
}
],
"coverage": {
"requested_max_results": 2,
"returned_results": 2,
"exhaustive": false,
"selection": "nonstop_alternatives"
}
}Download the complete example JSON · Read the field semantics · OpenAPI contract
Which workflows have been validated?
Local pilot validation is narrow. An airline name does not mean every route, date, passenger combination or operation is supported.
| Source | Locally validated scope |
|---|---|
| Ryanair | OPO–STN, one way, 1–2 adults |
| easyJet | OPO–LGW, one way, 1 adult; validated single-flight date shape |
| AEGEAN | LCA–ATH, one way, 1 adult; bounded nonstop starting quotes |
| Emirates / Qatar Airways | LCA–PVG, return, exactly 2 adults; bounded shortlist |
These tests used economy, English and EUR. Review the detailed source limitations and current API capability flags. Pilot activation and permitted use must be confirmed before live collection.
Where does it fit in your stack?
Use an observation as an input to your application or analysis. If you already use a booking API or commercial dataset, evaluate whether airline-website observations fill a specific gap. Farelint does not issue tickets, manage reservations or provide a mature historical fare warehouse.
Compare GDS data and airline website observations, or connect an AI agent through MCP.
What should a first pilot prove?
- Does the supported request match the trip and fields your product needs?
- Do prices reconcile against the same source, time and passenger context?
- Are completeness, usable result rate, freshness and cost suitable for your workflow?
Agree on these checks before expanding volume. Scheduled feeds, bulk exports and historical analytics are roadmap items; polling a completed job retrieves that observation rather than refreshing its price.