Aircraft
A new airframe or autopilot — expose its commands and telemetry once, and every mission type works with it.
One API between your system and a validated, multi-drone operation. You describe the objective; the platform handles the flight.
Autonomy projects are rarely blocked on the idea. They are blocked on everything underneath it — making an aircraft fly a route safely, legally and repeatably, with a dock that cycles and a radio link that drops. That work is the same for everyone building in this space, and none of it is what your customers are paying you for.
One API sits between the two. You never write the flight layer — the platform owns its validation, execution, and safety envelope, so your code stays on your side of the boundary.
The Mission API is not a remote control. You do not send waypoints, stick commands or camera triggers. You describe what the operation needs — a place, an action, a cadence — and the platform owns everything between that intent and the results landing back in your systems. That boundary is the integration.
The real lifecycle, one step at a time — enable an aircraft, describe the work, allocate, start, watch the telemetry, close it out. Signatures move between API versions, so take these as the shape of the work and the current reference from your key.
Nothing flies until an aircraft is enabled for automated work. This is the switch an operator or your system throws to put an airframe into the pool that allocation is allowed to draw from — and the one to throw back when it needs to come out for maintenance.
Why it mattersDo it first, or a valid mission will sit queued with nothing to fly it.
# put this airframe into the automated pool curl -X POST "$FO_HOST/api/enableAirVehicle" \ -H "Authorization: Bearer $FO_KEY" \ -H "Content-Type: application/json" \ -d '{ "airVehicleId": "M4TD" }' # -> { "success": true } # the inverse, when it comes out of service: # POST /api/disableAirVehicle
Post what the operation needs, not how to fly it. Here: a point to observe, the angle to observe it from, and the altitude to hold. No waypoints — the platform generates the route, follows terrain, and keeps it inside the volumes you are allowed to use.
Why it mattersThe mission exists now, but nothing is flying yet. It has no aircraft.
# intent: where to look, and from what angle curl -X POST "$FO_HOST/api/addPointMission" \ -H "Authorization: Bearer $FO_KEY" \ -d '{ "targetPoint": { "lat": 32.0853, "lon": 34.7818, "alt": 60 }, "azimuthToPoint": true, "viewingAngle": -35 }' # -> { "success": true, "missionID": "eveqipszge" } # other shapes for other jobs: # addRouteMission addSecurityMission # addDeliveryPointMission addDynamicPointMission
Allocation is its own call, deliberately. Name an aircraft when your operation cares which one flies. Say nothing and the platform chooses by readiness, energy and restrictions across every mission competing for the same fleet.
Why it mattersThis is the line between flying one drone and running an operation.
# explicit: this mission, that aircraft curl -X POST "$FO_HOST/api/allocateAirVehicleToMission" \ -d '{ "missionID": "eveqipszge", "airVehicleId": "M4TD" }' # -> { "success": true } # or skip this call entirely and let allocation decide. # to hand it back: POST /api/unallocateAirVehicleToMission
Start is where every validation runs: airspace and no-fly volumes, terrain, energy reserve, whether this airframe can actually do what the mission asks. A mission that cannot be flown safely is refused here, with a reason — not discovered in the air.
Why it mattersRead the failure body. It tells you which rule stopped you.
curl -X POST "$FO_HOST/api/startMission" \ -d '{ "missionID": "eveqipszge" }' # -> { "success": true } # -> { "success": false, # "description": "route intersects NFZ 'school_zone'" } # mid-flight control, if your operation needs it: # /api/pauseAirVehicle /api/resumeAirVehicle # /api/setAirVehicleAltitude /api/setGimbal
A mission is not a request and a response — it is minutes of changing state. Aircraft telemetry, mission phase transitions and AI detections arrive as events, so your system can act while the aircraft is still in the air rather than reading a report afterwards.
Why it mattersThis is the step integrations underestimate. Subscribe before you start.
const es = new EventSource(`${FO_HOST}/events?key=${FO_KEY}`); // where it is, how it is doing es.addEventListener('telemetry', (e) => { const t = JSON.parse(e.data); // { airVehicleId, lat, lon, altAgl, altMsl, battery, velocity } map.move(t.airVehicleId, t.lat, t.lon); }); // what it found, while it is still flying es.addEventListener('detection', (e) => { const d = JSON.parse(e.data); if (d.class === 'person' && d.confidence > 0.8) vms.raise(d); }); // queued -> validated -> allocated -> flying -> returning -> closed es.addEventListener('mission', (e) => ui.phase(JSON.parse(e.data)));
Stop closes the mission and brings the aircraft home through its normal return behavior — it is not a kill switch. When the mission closes, the artifacts are already assembled: detections tied to the frame that produced them, imagery, and the flight record behind all of it.
Why it mattersA closed mission is a record. That record is what a regulator asks for.
# close it out; the aircraft returns and docks curl -X POST "$FO_HOST/api/stopMission" \ -d '{ "missionID": "eveqipszge" }' # -> { "success": true } # bring an aircraft home without ending the mission: # POST /api/returnHomeAirVehicle # fly the same mission again, later: # POST /api/reExecuteMission
That is a complete mission. What it is not is a production program — the next conversation is about your fleet, your jurisdiction and your deployment model.
An autonomy program is not one product. It is a flight stack, a safety case, a hardware integration effort, a simulator and a regulatory file — and any one of them can sink a schedule on its own. Every row below is a system a team owns end to end, for the life of the product. Integrate against the Mission API and none of them is yours to build or maintain.
If you build it Every airframe, autopilot, dock, gimbal and payload speaks its own protocol, with its own handshakes, timeouts and firmware regressions. Supporting one vendor is not supporting the next.
On FlightCore Register the asset. It already speaks — connect and fly.
If you build it Geofences, terrain awareness, energy-reserve math, link-loss behavior, emergency landing points. Every one of them is a way to lose an aircraft, or hurt someone, if the logic is wrong.
On FlightCore Enforced under every mission you send — including the ones your code gets wrong.
If you build it To test safely you need a simulator that behaves like the fleet: same mission model, same validation, same telemetry. Building one honestly is a second product.
On FlightCore Fly a thousand missions against the same core before an airframe leaves the ground.
If you build it Real airframes in real weather and real RF conditions, cycling real docks. Simulation gets you to the runway; only flight hours prove the envelope holds.
On FlightCore Inherit hundreds of thousands of BVLOS flights already flown with customers.
If you build it BVLOS is not a feature you ship. It is a case you argue to an authority — per jurisdiction, with flight records and a safety argument behind it.
On FlightCore Fly under authorizations already granted in Israel, the US and Europe.
If you build it One drone is a demo. Many aircraft sharing airspace, docks and operators is a scheduling, deconfliction and allocation problem that grows with the fleet.
On FlightCore Name the outcome. Which aircraft flies it is the platform’s problem.
If you build it Live video, manual takeover, mission replay, reporting, audit trail. Everything operators need the day after the demo, and everything that makes an operation defensible.
On FlightCore Already in the console, and on the same API you integrate against.
A first mission runs in days, not months. Not because the API is small — because all seven rows are already behind it.
The platform speaks MCP, so an agent operates the fleet through the same validated path an operator uses. It proposes; the platform still refuses whatever fails validation — which is what makes handing a fleet to a model defensible.
plan_mission An objective becomes a mission the platform will accept. dispatch Send it to the fleet. Allocation automatic, or named. query_state What is flying, docked or queued, and what each aircraft is doing. read_results Detections, imagery and flight records once a mission closes. // register the fleet as a tool server { "mcpServers": { "flightops": { "url": "https://mcp.flightops.io", "headers": { "Authorization": "Bearer ${FO_KEY}" } } } } // then just ask: "inspect the north tank farm before the shift ends"
Today, supporting a new aircraft, dock, payload or AI engine is work FlightOps does. The Adaptor Factory (coming soon) will be an SDK that hands that work to you: write an adaptor once — the driver layer between a device’s own protocol and the platform’s mission model — and every mission type, validation rule and report already knows what to do with it.
Not yet available. It is on the roadmap, not in your key. Build against the Mission API and MCP today; tell us what you would want to adapt and we will bring you into the program when it opens.
The adaptor kinds the SDK will cover:
A new airframe or autopilot — expose its commands and telemetry once, and every mission type works with it.
Docking stations, gimbals, winches, sensors. Cycle logic and telemetry, not a fork of the platform.
Bring a detection or VLM model and it becomes selectable as an AI action on any camera action.
The same mission model applies indoors — the adaptor is what makes a non-flying asset addressable.
Tell us what triggers the work and what consumes the results — a person replies by email to scope the integration.
Cookies: this site uses the session cookies it needs to work, plus optional Google measurement cookies that help us understand site usage and campaign performance. Optional cookies load only if you accept. Details in our privacy notice.