Developers

Integrate autonomy
in an afternoon.

One API between your system and a validated, multi-drone operation. You describe the objective; the platform handles the flight.

01 / Why build on FlightOps

You build the product.
We provide 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.

What you build

  • Custom applications
  • Payload integrations
  • Data processing
  • Edge compute
  • Dispatch

What FlightOps provides

  • Aircraft, dock and payload drivers — already spoken for
  • The safety envelope: geofence, terrain, energy, link loss, emergency behavior
  • Airspace validation and BVLOS authorization
  • Allocation, scheduling and deconfliction across a fleet
  • Telemetry, live video, flight records and audit trail
  • A simulator that behaves like the real fleet

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.

02 / The integration model

You post intent.
We give you safe flight.

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.

Your side

Platform side — what you never write

  1. Trigger what starts the work
  2. Intent what the operation needs
  3. Consume what you do with results
  • safety
  • failsafes
  • geofencing
  • telemetry
  • GPS
  • flight authorization
  • link loss
  • routing
  • edge compute
  • energy
  • validation
  • dock cycles
  • restrictions
  • deconfliction
  • alerts
  • terrain following
  • hardware drivers
  • stream
  • no-fly volumes
  • authorize
  • communication
  • gimbal control
  • allocation
  • firmware quirks
  • AI detection
  • protocol handshakes
  • airspace
  • winch & payload
  • simulation
  • weather
  • UTM / USSP
  • camera actions
  • collision avoidance
  • VLM engines
  • return-home
  • ADS-B
  • multi-drone
  • photogrammetry
  • flight records
  • 3D models
  • BVLOS evidence
  • manual takeover
  • change detection
  • scheduling
  • emergency points
  • field testing
  • audit trail
  • low-latency video
  • datalake
  • reporting
  • regulatory filing
03 / A sample mission

One mission,
start to finish.

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.

Step 01 of 06

Enable the aircraft

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.

enable.sh
# 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

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.

04 / What you don’t build

Don’t build the stack.
Build on it.

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.

  1. 01 Hardware integration

    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.

  2. 02 The safety envelope

    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.

  3. 03 A simulation environment

    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.

  4. 04 Flight hours

    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.

  5. 05 Regulatory evidence

    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.

  6. 06 Fleet coordination

    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.

  7. 07 Operational tooling

    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.

05 / Agents

Your agent gets
a fleet as a tool.

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.
mcp.json
// 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"
06 / Extending the platform

Adaptor Factory. Coming soon

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:

Aircraft

A new airframe or autopilot — expose its commands and telemetry once, and every mission type works with it.

Docks & payloads

Docking stations, gimbals, winches, sensors. Cycle logic and telemetry, not a fork of the platform.

AI engines

Bring a detection or VLM model and it becomes selectable as an AI action on any camera action.

Ground robots

The same mission model applies indoors — the adaptor is what makes a non-flying asset addressable.

Request
developer access.

Tell us what triggers the work and what consumes the results — a person replies by email to scope the integration.

WhatsApp