Build with the physics engine

POST /api/v1/crash reads a flight log after an incident. The body is the log file itself, raw binary, not multipart and not base64, and the format is detected from the file’s own bytes: ArduPilot dataflash (.bin), MAVLink telemetry (.tlog), PX4 ULog (.ulg), DJI flight records (DJIFlightRecord .txt, including current encrypted ones), Parrot FreeFlight JSON, GUTMA flight-logging JSON, Litchi / Airdata / DJI GO flight-log CSV, and Betaflight / INAV Blackbox (.bbl). Needs the Crash Analyzer add-on on the account (otherwise 402); 64 MB maximum; one metered unit, charged only once the upload is accepted.

Copycurl -X POST "https://app.rotorlab.app/api/v1/crash?name=flight.bin"   -H "Authorization: Bearer rl_your_key" -H "Content-Type: application/octet-stream"   --data-binary @flight.bin
# crash.detected · crash.reason · crash.confidence (high | medium | low)
# preconditions.findings[] · timeline[] · meta.vehicle · meta.source_format
# diagnostics.findings[] · diagnostics.battery.internal_resistance_mohm
# diagnostics.ekf.worst_ratio · diagnostics.compass.throttle_field_r
# add &charts=1 for ready-to-embed SVG charts (roughly triples the response)

The log waits in line to be read, like every log uploaded to RotorLab. By default the call waits for the reading and answers with it. To be answered at once instead, add &async=1 (or send the header Prefer: respond-async): the answer is 202 with a token, the log’s place in line and a status_url. Ask GET /api/v1/crash/{token} with the same key every few seconds: 202 while it waits, then the reading in the same shape as above. Asking is not metered, only the member whose key sent the log can ask, and the reading is kept for 7 days after it is ready. A call whose log is not read within nine minutes, or that arrives while many calls are already waiting, is answered 503 with a Retry-After header, and its body carries the same token and status_url, so the reading is never lost: asking for it costs nothing more. Five logs from one member may wait at once; a sixth is answered 429 before it is metered.

Copycurl -X POST "https://app.rotorlab.app/api/v1/crash?name=flight.bin&async=1"   -H "Authorization: Bearer rl_your_key" -H "Content-Type: application/octet-stream"   --data-binary @flight.bin
# 202 {"queued": true, "token": "...", "status_url": "/api/v1/crash/...", "position": 1, "ahead": 0}
curl "https://app.rotorlab.app/api/v1/crash/TOKEN" -H "Authorization: Bearer rl_your_key"
# 202 while it waits, then 200 with the reading

The diagnostics block covers pilot input against autopilot action, estimator innovation test ratios (1.0 is the rejection threshold), pack internal resistance fitted from the flight’s own current draw, compass interference, GPS quality and accelerometer clipping. Every section carries available: when it is false it carries a reason rather than numbers, so a log that never recorded a magnetometer returns no compass reading instead of a zero. Check available before reading a section.

This instance serves a read-only Model Context Protocol endpoint at POST https://app.rotorlab.app/mcp. Point any MCP-speaking assistant (Claude, or your own agent) at it with an API key that includes the AI assistant (MCP) reads area, sent as Authorization: Bearer rl_…, and it can ask questions of your organization’s records: the aircraft register with airworthiness states, per-aircraft health trends, recent flights, open work and occurrences, battery packs with their retirement horizons, the readiness meter, and the measured maintenance experience (repair verification and component survival).

Copycurl -X POST https://app.rotorlab.app/mcp \
  -H "Authorization: Bearer rl_your_key" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"recent_flights","arguments":{"limit":10}}}'
# result.structuredContent.flights[] · result.structuredContent.next_cursor

The endpoint is read-only by construction: there is no writing tool, the key’s organization is the boundary for every read, and no tool returns member lists, emails, or pilot identities. A key’s holder sees only the tools their role reads. Unscoped keys from before areas existed pass as they do everywhere else.

• Transport. Streamable HTTP with one JSON response per POST; protocol revisions 2025-06-18, 2025-03-26 and 2024-11-05. It opens no event stream and keeps no sessions, so GET and DELETE answer 405 with Allow: POST. A JSON-RPC batch is answered for 2025-03-26 and 2024-11-05 and refused for 2025-06-18, which removed batches.
• Tools. Every tool has an input schema describing each argument, an output schema, and the read-only annotations, so a client can run them without asking. Each result carries structuredContent and the same JSON as text.
• Times and units. Times are ISO 8601 with your organization’s offset, like 2026-10-03T14:05:00-05:00; a date alone is a calendar day. Units are in the field names or the output schema: hours, duration_min, threshold_mohm.
• Paging. recent_flights returns at most 50 flights a page (20 by default); send its next_cursor back as cursor for the next page.
• Errors. A missing, misnamed or unreadable argument is JSON-RPC -32602 saying what the tool takes; aircraft_health lists the aircraft names in error.data.aircraft. An unknown tool name is -32602 too, naming the tools in error.data.tools. A body that is not JSON is -32700, and one that is not a JSON-RPC request -32600. A bad or missing key is HTTP 401, and a key without the MCP area, or a holder still owing two-factor or single sign-on, HTTP 403, both with JSON-RPC -32001.
• Limits. MCP calls spend no quota or credits. Each key may send 60 requests a minute and 1,000 an hour, each request in a batch counting once; past that the answer is HTTP 429 and JSON-RPC -32029, with Retry-After giving the seconds until the request fits.

The live cockpit natively decodes MAVLink and MSP byte streams that a relay agent sends through your organization's cloud relay. The relay is view-only and belongs to your organization: each agent signs in with one of the organization's device keys, minted on the Live Telemetry page and shown once, only members of that organization can watch it, and nothing travels back toward the aircraft. For a source with no byte protocol, a vendor cloud API, a custom tracker, a simulator, RotorLab telemetry (RLT) is the documented third way in: your adapter dials the same relay endpoint the standard agent uses, with a device key in the Authorization header (never in the address), and sends one JSON object per binary WebSocket frame. The relay never parses telemetry, so an adapter needs nothing server-side beyond its device key.

wss://<your-server>/relay/agent      (Authorization: Bearer rlrd_xxx)

{"rlt": 1, "src": "my-adapter", "t": 1755672000.1,
 "lat": 42.5006, "lon": -90.6646, "alt_m": 241.0, "rel_alt_m": 41.0,
 "roll": 2.1, "pitch": -4.8, "yaw": 231.0,
 "volt": 22.9, "curr": 14.2, "rem_pct": 71, "thr_pct": 48,
 "gs_ms": 8.4, "as_ms": 8.9, "vs_ms": -0.3, "sats": 17, "fix": "3D",
 "vehicle": "My quad", "serial": "SN123", "mode": "Auto",
 "armed": true, "commandable": false}

rlt, src and t (unix seconds) are required; every other field is optional. Absent means your source does not report it: the cockpit shows the gap rather than a made-up value, so never send zeros for readings you don’t have. Units are fixed in the field names (meters, m/s, volts, amps, degrees, percent). mode and fix are plain display strings; map your source’s enums yourself. RLT links are receive-only: declare commandable: false; the relay sends your adapter no data. Viewers in your organization open the device on the cockpit and pick Any aircraft (RotorLab telemetry) as the protocol; recording and replay work unchanged. A complete reference adapter that flies a scripted flight ships in the server tree as tools/rlt_demo_agent.py.

A metered call spends one unit; the endpoint table says which are. The engine, your saved builds and uploading a log for forensics are metered. Everything that files or reads your organization’s own records is not: flights, checklists, missions, pilots, aircraft, work orders, components, types, service bulletins, health and scores are free, so filing a record is never stopped by a quota and a lapsed plan never blocks a flight record. version and usage are free too, so a blocked client can still read its own status, and asking after a queued log reading costs nothing. A refused call and an unknown path spend nothing: a body is checked whole before anything is metered, and a call refused after that gives its unit back. The one exception is a crash log that is accepted and then cannot be read: it counts as one call.

Your plan sets a daily quota (resets at 00:00 UTC), spent first. Once it’s gone, calls draw from your organization’s credit balance: credits come included with some plans, can be granted by an admin, or purchased from Organization, Billing, API credits when purchasing is enabled. When both are spent the API answers 429 with Retry-After set to the reset. A plan that includes no API calls at all answers 402 instead, with quota: none and no Retry-After: waiting will not help, credits or a plan that includes calls will.

Every error is JSON with an error sentence that says what to do; the fields beside it let a program branch without reading the sentence.