The ofp hub connects flight planning systems, PPS first, and keeps one record per flight: the plan, the release, the crew's reports. iPad, web and terminal clients get everything from the hub, including the flight folder for the cockpit.
Flight planning systems feed one canonical record per flight. Clients talk only to the hub: they get the flight, its events and its flight folder, and send back what the crew records.
planned
Keeps one record per flight: the plan, its release, every recalculation, and what the crew reports after the flight. Each planning system connects through its own adapter; PPS is the first, and the hub asks it for changes every minute.
Everything is a REST call with JSON in return, described in OpenAPI. Systems that need to react subscribe to events: signed, retried and replayable.
How the ofp hub works$ curl -H "Authorization: Bearer $KEY" \
https://pps.example/v1/flights/7069a5af…/phase
{
"id": "7069a5af-…",
"phase": "airborne",
"phase_updated_at": "2026-10-09T14:51:00Z"
}
ofp is the dispatcher's screen in a terminal: the day's flights with their status, the exception board, and for each flight its plan, NOTAMs and weather. Free for macOS and Linux.
A route map in the browser draws a flight's route in 2D, 3D or on a globe, with its vertical profile. iPad apps build on the Swift client and web apps on the TypeScript client, both generated from the same API description. Every client talks to the hub only.
See ofpSTD IN FLIGHT ROUTE STS PH !
── now 14:05Z ────────────────────────────
> 14:45Z T-0:40 MK142 LSZH→LIRN RCL PRE ⚠2
15:30Z T-1:25 MK149 EDDF→LEMD REL SCH
16:10Z T-2:05 MK156 LFPG→EGCC MOD SCH ⚠1
17:00Z T-2:55 MK163 ENGM→ENBR PLN SCH
Questions about the ofp hub or ofp? Get in touch.