flighthelp for builders

Open, neutral, audited infrastructure for everything that touches air-travel facts and passenger rights. Schemas, a rules engine, and a verified continuously-updated dataset. Free, permissively licensed, structurally non-commercial.

You are reading this because you are building something — an AI assistant, a booking platform, a corporate travel tool, a travel insurance product, a journalism investigation, an academic dataset, a claims service, a comparison site — and you need facts about airlines, airports, baggage policies, contact methods, fees, and passenger rights that are correct, current, and citable.

This is the documentation for the layer that should already exist. It now does.

What you get

The schemas (flighthelp/schema, MIT). Versioned JSON Schema definitions for every entity in the air-travel domain: airlines, airports, baggage rules, contact methods, fees, scenarios, regulations, contributors, sources. Each schema is documented field-by-field. Each schema generates language-bound types for TypeScript, Python, Go, PHP, Rust, Java, and Swift. Each schema is versioned with strict semver and a public migration policy.

If you are modeling air-travel data, start here. The schemas exist so you do not have to invent them. Adopting them gives you compatibility with every other project that has adopted them — including, increasingly, your competitors' products and your AI provider's training data.

The rules engine (flighthelp/rules-engine, MIT). A standalone library implementing passenger-rights logic for every relevant regime: EC 261/2004, UK 261, ANAC Resolution 400, the Montreal Convention, US DOT regulations, Canada APPR, India DGCA, Israel Aviation Services Law, and others. The engine takes a structured scenario and returns eligibility, legal basis, compensation amount, time limits, and required next steps.

Every rule is tied to a specific article of law and, where applicable, to case law. The engine is versioned independently so you can pin to a specific legal interpretation. Three hundred-plus test fixtures per regime ensure the engine returns the same answer for the same inputs across releases. Available as @flighthelp/rules-engine on npm, flighthelp-rules-engine on PyPI, and flighthelp/rules-engine on Composer. Other languages follow.

The dataset and API (api.flighthelp.net). Continuously updated verified facts on every airline and major airport in the world, served through a free REST and GraphQL API. Bulk downloads under CC-BY 4.0. Webhooks for entity-change subscriptions. Provenance metadata on every response: verification timestamps, verifier counts, source URLs.

Three free tiers cover the vast majority of consumers. A paid commercial tier (with SLAs and support) is available for high-volume use and funds the project's operations.

What this is good for

AI assistants and retrieval systems. Ground your model in current, citable airline facts instead of hallucinating. The API returns sources with every claim — show them to the user. Use the rules engine to answer "am I owed compensation" questions correctly instead of guessing. Subscribe to webhooks so your retrieval cache stays current automatically.

Online travel agencies and booking platforms. Add accurate baggage allowances, fees, and contact information to your product without maintaining the dataset yourself. Use the rules engine to surface passenger rights at the moment of booking and after disruptions. Stop paying competitors' overhead by paying the project once for commercial-tier access.

Corporate travel platforms. Duty-of-care obligations require accurate, current information about traveler rights and disruption response. The API gives you that. The engine gives you defensible compensation logic. The webhook subscriptions let you proactively notify travelers when their rights change mid-trip.

Travel insurance underwriters and claims processors. Automate claim eligibility for disruption-related products. The engine's legal references make your decisions defensible. Pin to a specific engine version for consistency across a policy term. Use the dataset to validate route, carrier, and timing claims.

Claims companies (yes, including the major existing ones). Replace your privately-maintained, expensive-to-update, frequently-incorrect internal compensation logic with an audited public engine. Your customers get a more trustworthy answer. Your legal exposure goes down. Your engineering team works on the parts of the product that actually differentiate you.

Journalism and research. Cite the dataset. Reproduce findings. Query historical snapshots for time-series analysis of fee changes, route changes, policy shifts. Use the source attribution to trace any claim back to its origin.

Government and regulators. Reference the engine in policy work. Compare your interpretations of the regulations to the engine's test fixtures. Use the dataset for consumer-protection enforcement.

What the project promises

The data and code stay open. CC-BY 4.0 on the dataset, MIT on the schemas, scrapers, engine, and SDKs, AGPL on the reference website. The non-profit governance makes lock-up impossible: there is no future board, no future acquirer, no future funding crisis that can take these licenses back.

The schemas and engine are versioned for stability. Strict semver. Documented migration paths. Long support windows for major versions. You can build something on flighthelp v3 and know that the v3 schemas and engine remain available even after v4 ships.

The API is operated with the care of paid infrastructure. The free tier is rate-limited, not throttled to uselessness. The paid tier has real SLAs (99.9% target). Status page, public incident reports, public roadmap. If something breaks at 3 AM, someone is paged.

Provenance is not optional. Every response from the API includes the source. Every rule in the engine cites the law. If a fact is wrong, you can trace exactly where it came from and when it was verified. This is the feature that makes the data citable in production systems.

There are no editorial preferences. No airline is ranked higher than another for commercial reasons. No claims service is recommended. No booking site is preferred. The project has no commercial relationships that affect what the data says.

What the project asks of you

If you use the data publicly, credit it. CC-BY 4.0 attribution: link back to flighthelp.net or the relevant dataset endpoint. This is the entire ask for free use.

If you use the API at commercial scale, pay for the commercial tier. Not because the data is gated — the same data is in the bulk downloads — but because the commercial tier funds the operation that makes the free tier sustainable. The pricing is designed to be obviously fair: it scales with your usage, with no upsell mechanics.

If you find data that's wrong, report it. The project gets better through corrections. Every page has an edit link. Every API response has a "report this fact" link. The moderation queue processes corrections within hours.

If you build something useful on top, tell us. Not for promotional reasons; so we know what schemas and endpoints need investment. The project's roadmap is shaped by the things builders actually need.

What this is not

Not a search engine for flights. The project does not aggregate or sell flight inventory. There is no Amadeus, Sabre, or Travelport integration. Use Duffel, Kiwi, or the GDS partners for that.

Not a real-time operational data feed. The dataset is about policies and facts, not about live flight status. The data refresh cadence is hours-to-days, not seconds.

Not a paid SaaS dressed in open clothing. The free tier is genuinely sufficient for most consumers. The commercial tier exists for scale and SLA, not for unlock.

Not a vendor. The project is a non-profit. You cannot acquire it. You cannot sponsor your way into editorial decisions. You can fund it, and the funding will be acknowledged in the transparency report, and nothing about the data will change.

Where to start

• Schemas: github.com/flighthelp/schema — read the README, browse the JSON Schema files, install the language bindings you need.
• Rules engine: github.com/flighthelp/rules-engine — read the engine README, install the SDK for your language, run the playground.
• API docs: api.flighthelp.net/docs — start with the unauthenticated tier, hit a few endpoints, then register for a key when you need more.
• Bulk dataset: github.com/flighthelp/data — daily snapshots in /snapshots/daily/.
• Status and incidents: status.flighthelp.net.

If you are evaluating whether to build on the project for something production-grade, the team is reachable at builders@flighthelp.net. There is no sales pitch. There is no qualification process. The infrastructure is the pitch.