Sections

The whole reference in one file for agents: llms-full.txt, and as openapi.json.

API reference

RAIM route check

Available

POST /v1/raim/route

A flight plan flown along great-circle legs, RAIM evaluated at the aircraft's position and time at every step. The flight is the flight object (see Flight object): waypoint times may be given, or computed from departure and speed_kt; a waypoint's level may be alt_m, alt_ft or fl, and is flown in metres; label is read as id, and codes are accepted and not used. phase or hal_nm applies from a waypoint onwards (the first must have one); a leg is flown against the smaller HAL of its two ends. Beside the flight: window_minutes, detail and the same tuning fields as predict (profile, constellations, step_seconds, mask_deg, fde, baro, outages, ...).

{ "departure": "2026-09-18T08:00:00Z", "speed_kt": 450, "profile": "faa-c129",
  "waypoints": [
    { "id": "LOWW", "lat": 48.1103, "lon": 16.5697, "alt_m": 183, "phase": "terminal" },
    { "id": "TOC",  "lat": 48.9, "lon": 12.5, "alt_m": 11000, "phase": "enroute" },
    { "id": "EGLL", "lat": 51.4706, "lon": -0.4619, "alt_m": 25, "phase": "approach" }
  ] }

Or give the route as filed instead of waypoints: route (a string), with phase (default auto) or hal_nm, and the cruise level as cruise_alt_m or cruise_fl (optional; cruise_fl: 350 flies at 10,668 m). auto takes the phases from the route's airports: terminal (1.0 NM) from the departure airport until the route first leaves 30 NM of it, and from the last time it comes within 30 NM of the destination; approach (0.3 NM) from the last time it comes within 7 NM of the destination; en route (2.0 NM) everywhere else. These zones exist only where the route starts or ends at an airport, and a later pass near either airport stays en route. Where a zone starts or ends inside a leg, a point is added there (kind: "boundary", ids such as KMSP+30NM, KSFO-30NM, KSFO-7NM) carrying the looser phase, so each leg is flown against its own zone's limit; every point in resolved_route.points then has its phase. Any other phase, or hal_nm, holds for the whole route. Departure and destination airports sit at field elevation, every other point at the cruise level (without one, at its own elevation). Airports and navaids come from OurAirports (worldwide); named fixes, airways and SIDs/STARs from the FAA CIFP (US airspace, including Alaska, Hawaii and the US oceanic areas), using the AIRAC cycle in force at departure. An airway (V170, J148) is expanded into its fixes between the entry and the exit. SID.TRANSITION after the departure is flown on the SID's common route then the transition; TRANSITION.STAR before the destination on the transition then the common route; runway-specific legs are left out because the runway is not known, and legs without a fix (headings, vectors) are skipped. A retired revision (MOD5) is flown as the current one (MOD9) with a note. Coordinates (5020N01000W, 52N020W, 4413N/09354W, N44.2/W93.9, 44.2/-93.9) are placed as given; DCT and speed/level groups (N0450F350) are dropped. An airway or procedure outside the US data is flown direct, with a note. An identifier shared by several places resolves to the one on the way. A fix we cannot place (KOXER outside the US) is a 422 route_unresolved with unresolved[], never a guess. The response adds resolved_route with route, points[] (token, id, kind airport/navaid/fix/coordinate, or boundary with phase: "auto", type, name, country, lat, lon, elevation_ft, matches, via: the airway or procedure a fix comes from), notes[], one per simplification, and nav_data (source, airac, effective_from, effective_to).

{ "route": "KMSP DWN6.ABR J158 RAP MBW MTU J148 OAL.MOD5 KSFO", "departure": "2026-09-23T18:00:00Z",
  "speed_kt": 450, "cruise_alt_m": 10700, "phase": "enroute", "profile": "faa-c129" }

Response: dispatch (the verdict), summary, start, end, duration_s, distance_nm, availability_pct, outages[] with from/to time and position, leg, reason, max_hpl_m, hal_nm; worst (HPL, time, position, leg); waypoints[] (each fix at its own time: hal_nm, available, hpl_m, sats); legs[] (from, to, hal_nm, distance_nm, samples, epochs_available, outages); plus almanac, params, outages_applied, warnings, degraded. detail: true adds samples_detail with t, lat, lon, hpl_m, sats, avail.

summary is the verdict in one to three plain sentences, for example: "RAIM is available along the whole route for the planned departure 12:00Z. Every departure from 11:46Z to 12:26Z is clean (14 min early to 26 min late). Departing 11:17Z to 11:45Z loses RAIM between p1 and p6 (HAL 0.1 NM)." Show it to people as it is; use the fields for logic.

Departure window

A timed track, for example exported from a flight plan, with its own alert limit per point, checked for a departure that may slip by up to two hours either way:

{ "profile": "faa-c129", "window_minutes": 120,
  "waypoints": [
    { "id": "KSFO", "lat": 37.6188, "lon": -122.3750, "alt_m": 4,     "time": "2026-09-24T12:00:00Z", "hal_nm": 0.1 },
    { "id": "CLB",  "lat": 37.7400, "lon": -121.9800, "alt_m": 1800,  "time": "2026-09-24T12:05:00Z", "hal_nm": 0.3 },
    { "id": "TOC",  "lat": 38.1500, "lon": -120.4000, "alt_m": 10700, "time": "2026-09-24T12:20:00Z", "hal_nm": 2.0 },
    // ... en route points, up to 500 waypoints in all
    { "id": "TOD",  "lat": 40.9000, "lon": -75.9000,  "alt_m": 10700, "time": "2026-09-24T17:02:00Z", "hal_nm": 1.0 },
    { "id": "FAF",  "lat": 40.6700, "lon": -73.9000,  "alt_m": 600,   "time": "2026-09-24T17:17:00Z", "hal_nm": 0.1 },
    { "id": "KJFK", "lat": 40.6398, "lon": -73.7789,  "alt_m": 4,     "time": "2026-09-24T17:20:00Z" }
  ] }

A leg takes the smaller HAL of its two ends, so put a point where a tighter limit starts (above, the leg from TOD to FAF is flown against 0.1 NM).

window_minutes (0 to 720, default 0) is how far the departure may slip. The whole schedule is shifted by every step_seconds within that many minutes either side of the planned times, and each shifted flight is judged with the same outage rule as the planned one. The cost is departures times samples along the route, at most 250,000 per request: 152 points over 5 h 20 at ±120 min is 241 x 454, well inside it; a longer route or window gets a 422 saying by how much, and a larger step_seconds brings it back.

With a window the response adds:

  • window: planned_departure, planned_ok (the same verdict as dispatch.ok), minutes, step_s, departures_checked, clean_pct (share of the checked departures that are clean), slack_minutes (early, late: how far the departure can move with every departure in between clean; equal to minutes when it stays clean to the edge of the window; null when the planned departure fails), nearest_clean (only when the planned departure fails: earlier and later, each { "departure", "offset_min" } or null), clean_departures[] and blocked_departures[] (from, to, from_offset_min, to_offset_min, both ends inclusive and sampled every step_s; each blocked range lists segments[], where those departures lose RAIM: from_id, to_id, first_leg, last_leg, the smallest hal_nm there, reasons, max_hpl_m, longest_outage_s) and fixes_ok.
  • waypoints[].window: that fix held at its position from its time minus the window to its time plus the window: start, end, epochs, epochs_available, availability_pct, ok, outages[]. This is what predict returns for the same point and window. It is stricter than the departure view, because the aircraft does not stay at a fix; fixes_ok is true when every fix passes.
  • With detail: true, window_detail: offset_start_min, step_s, rows, row_ok[] and unavailable runs [row, first sample, last sample] indexing samples_detail, enough to draw departure time against distance along the route.

Reading it: planned_ok answers "is the planned flight covered", slack_minutes "how much delay or early departure it can take", blocked_departures[].segments "where the others lose RAIM", and fixes_ok the stricter per-point question.