What people build with OpenFlight

Airline operations

Irregular-ops desks that see problems forming

A regional carrier's ops center used to run delay review meetings off a screen-scraped feed that was 20 minutes behind reality. Their dispatchers now watch a board built on our webhooks: every flight.departed, gate.changed and flight.diverted event lands in under two seconds, and delay predictions run hourly against their bank of rotations.

The part they tell us matters most isn't the speed — it's the predictions. Knowing a bank of evening departures out of Denver is trending 25 minutes late before the first aircraft pushes back gives crew desk three extra decisions' worth of runway. Median error on their routes is under 9 minutes at departure minus three hours, which they've learned to trust but not to worship, exactly as it should be.

Travel apps

"Where's my plane," answered honestly

Trip trackers are the classic use case: a traveler books a flight, your app watches it, and the day-of experience is a live card with gate, delay estimate and terminal instead of a static confirmation number. Most of our travel-app customers live on two endpoints — GET /flights/{id} and the departure board query — plus one webhook per active itinerary.

The unglamorous detail that decides whether this works: caching. A travel app's day-of traffic is spiky and concentrated in the three hours around departure. Respect the cache headers, batch what you can, and a Hobby or Pro tier goes a long way. The apps that get a 429 problem are almost always polling one flight every second for 40,000 itineraries; the fix is a webhook and a database, and it's cheaper than the tier upgrade they usually assume they need.

One limitation worth knowing: we deliberately don't serve seat-level or passenger data, so anything "will there be an open seat next to me" needs a different product. We're an API, not a crystal ball.

Logistics & freight

Ground crews timed to the actual arrival

A freight forwarder's high-value cargo team used arrival scheduled times to plan warehouse staffing. Anyone who has stood at an airport curb at 2am waiting for a flight that left late knows how that goes. They now key their dock scheduling off predicted and then actual arrival times, with the webhook telling their dispatch system when wheels-down actually happens.

Over six months they cut paid idle dock time by roughly a fifth — we'd love to claim the API did that, but honestly their dispatchers did; the API just stopped lying to them about when airplanes arrive. Cold-chain shipments get the tightest integration: temperature-controlled cargo can't sit, so a 40-minute heads-up on a delay isn't convenience, it's the difference between re-icing and not.

Aviation analytics

Route networks, frequency shifts and the stories in schedules

Consultancies, aviation media and two very persistent hobbyists use the schedules and routes endpoints to see what carriers are actually doing: new routes before the press release, frequency cuts on routes that are quietly dying, and aircraft rotations that reveal which frames an airline is willing to park overnight at a spoke.

Twelve months of forward schedules across 3,900 airports is a lot of rows, so the analytics crowd mostly pulls deltas — carrier change files, applied nightly — rather than full refreshes. A typical setup: nightly batch job into Postgres, GraphQL for interactive dashboards on top, and a route-network pull when a client asks "should we worry about Carrier X showing up in our hub." One analytics shop we know found a cargo conversion program three weeks before the trade press by watching fleet rotations. They were unbearably pleased with themselves, and fair enough.