Missions

A mission is one robot's execution of a piece of work. When you deploy an operation, it runs as one or more missions across the assigned robots. The endpoints here let you schedule missions, manage reusable templates, and read mission and operation history.

What it represents

• A mission run is a single execution of work by one robot, with a status that updates as the robot works (for example ready, running, completed, or error).
• An operation groups the missions deployed together from one plan.

This page covers reading mission and operation history, scheduling missions, and managing reusable mission templates. For richer multi-robot jobs (such as hauling), use the plan lifecycle instead.

Scheduling at a glance

The scheduling and template endpoints, in one place. Nested paths are shortened to … for /v1/orgs/{org_id}/fleets/{fleet_id}.

To do this	Endpoint	Permission
Schedule a mission (live)	POST …/missions	missions:write
Record a schedule without dispatching	POST /v1/mission-schedule	missions:write
List scheduled missions	GET …/mission-schedule	missions:read
Cancel a scheduled mission	DELETE /v1/mission-schedule/{mission_id}	missions:write
Create a mission template	POST …/mission-templates	missions:write
List or get mission templates	GET …/mission-templates	missions:read
Update or delete a template	PUT / DELETE /v1/mission-templates/{mission_id}	missions:write
Schedule a command (start/stop an operation, and so on)	POST …/scheduled-commands	operations:control
List scheduled commands	GET …/scheduled-commands	missions:read
Delete a scheduled command	DELETE …/scheduled-commands/{schedule_id}	operations:control

Missions and commands schedule through separate endpoints: a mission command sent to …/scheduled-commands is rejected, so schedule missions through …/missions.

Authentication

All endpoints here are called with an API key. See Authentication. The permission each endpoint needs is noted inline; reads use history:read or missions:read, writes use missions:write.

The two history endpoints are cursor-paginated: pass cursor (epoch milliseconds) to continue from a previous page, and next_cursor in the response is the value to pass next, or null on the final page. Both accept start_time / end_time (epoch milliseconds) and limit (1 to 200, default 50).

Mission run history

GET /v1/orgs/{org_id}/fleets/{fleet_id}/history/missions

Returns past mission runs in the fleet, newest first. Permission: history:read.

Additional filters: robot_id, mission_id, status.

Response:

{
  "items": [
    {
      "run_id": "run-uuid",
      "mission_id": "mission-uuid",
      "robot_ref": "a1b2…",
      "status": "completed",
      "progress_pct": 100.0,
      "name": "Morning sweep",
      "time_started": "2026-06-18T08:00:00Z",
      "time_completed": "2026-06-18T08:42:00Z",
      "updated_at": "2026-06-18T08:42:00Z"
    }
  ],
  "next_cursor": null
}

Operation history

GET /v1/orgs/{org_id}/fleets/{fleet_id}/history/operations

Returns past operations in the fleet, newest first. Permission: history:read.

Additional filter: status.

Response:

{
  "items": [
    {
      "operation_id": "op-uuid",
      "name": "Pit to Stockpile",
      "status": "completed",
      "priority": 1,
      "created_by": "user-or-key-id",
      "robot_refs": ["a1b2…", "c3d4…"],
      "created_at": "2026-06-18T07:55:00Z",
      "updated_at": "2026-06-18T08:42:00Z"
    }
  ],
  "next_cursor": null
}

For the live status of a running operation, use the operation feedback and progress endpoints.

Recent mission runs (top-level)

GET /v1/mission-runs?fleet_id={fleet_id}&days={n}

A top-level alternative to the mission history above that returns a richer record per run (status message, current step and target, dispatch failure reasons, and both epoch-millisecond and ISO timestamps), over a recent window. Permission: fleet:read. days is optional (default 7, maximum 30).

Response:

{
  "missionRuns": [
    {
      "runId": "run-uuid",
      "missionId": "mission-uuid",
      "robotId": "a1b2…",
      "robotName": "Rover-1",
      "missionName": "Morning sweep",
      "userName": "Jordan",
      "status": "completed",
      "statusMessage": null,
      "progressX100": 10000,
      "currentStep": 7,
      "totalSteps": 7,
      "timeStarted": "2026-06-18T08:00:00Z",
      "timeCompleted": "2026-06-18T08:42:00Z",
      "dispatchFailReasons": null,
      "updatedAt": "2026-06-18T08:42:00Z"
    }
  ]
}

progressX100 is percent times 100 (so 10000 means 100%). Prefer the cursor-paginated mission history for large result sets.

Schedule a mission

POST /v1/orgs/{org_id}/fleets/{fleet_id}/missions

Schedules a single mission on one or more robots. If the start time is now or in the past, it fires immediately; with a schedule, it runs one-time or recurring. Permission: missions:write. Requires the Idempotency-Key header.

Request body (a mission definition plus the robots to run it on):

{
  "name": "Morning sweep",
  "robotIds": ["a1b2…", "c3d4…"],
  "detail": "",
  "scheduledStartMs": 0,
  "capabilities": ["mowing"],
  "missionParameters": [],
  "featureId": "feature-uuid",
  "templateMissionId": "template-uuid",
  "schedule": null
}

• name (required): the mission name.
• robotIds (required): the robots to run on. Every robot must belong to the fleet in the path.
• scheduledStartMs (optional): epoch milliseconds for the start. 0 or omitted means start now.
• schedule (optional): a recurring or one-time schedule. Omit for a single immediate run.
• templateMissionId (optional): a mission template to inherit capabilities, missionParameters, and prerequisites from for any of those fields you leave empty.
• featureId (optional): a feature the mission targets. It must belong to the fleet.
• missionId (optional): omit to have the server mint one.

Response:

{ "missionId": "mission-uuid", "status": "scheduled" }

Record a schedule without dispatching (top-level)

POST /v1/mission-schedule

A top-level variant that writes a scheduled-mission row and its robot assignments to the database but does not register it with the live scheduler, so it will not fire until the server next loads schedules. Use it to seed schedules for external systems; for a mission that should run now or on a live schedule, use Schedule a mission instead. Permission: missions:write.

The body is the snake_case schedule row. mission_id (client-supplied), name, and fleet_id are required; robots are given as robot_ids (a UUID array), and the optional schedule_kind / schedule_cron_expr / schedule_every_seconds fields describe recurrence. The response echoes the stored row.

List scheduled missions

GET /v1/orgs/{org_id}/fleets/{fleet_id}/mission-schedule

Returns the fleet's scheduled missions, newest first, as { "items": [ … ] }. Permission: missions:read. Optional query params: limit (1 to 200, default 50) and a start_time / end_time window (epoch milliseconds) matched against each mission's scheduled start.

Cancel a scheduled mission

DELETE /v1/mission-schedule/{mission_id}?fleet_id={fleet_id}

Removes a scheduled mission and its robot assignments. Permission: missions:write. Response:

{ "success": true }

Mission templates

A mission template is a reusable mission definition you can schedule from later.

Method and path	Description	Permission
GET …/mission-templates	List the fleet's templates, newest first, as { "items": [ … ] }. Optional limit (1 to 200, default 50) and a start_time / end_time window (epoch milliseconds) matched against each template's creation time.	missions:read
GET …/mission-templates/{mission_id}	Get one template (404 if not in the fleet).	missions:read
POST …/mission-templates	Create a template; the server mints the mission_id. Returns 201.	missions:write

Create request body:

{
  "name": "Perimeter mow",
  "detail": "",
  "capabilities": ["mowing"],
  "missionParameters": [],
  "featureId": "feature-uuid",
  "prereqs": []
}

Create response (201 Created):

{
  "success": true,
  "missionId": "template-uuid",
  "fleetId": "fleet-uuid",
  "message": "Mission template \"Perimeter mow\" created successfully"
}

POST …/mission-templates requires the Idempotency-Key header. Updating and deleting templates is done through the top-level endpoints PUT /v1/mission-templates/{mission_id} and DELETE /v1/mission-templates/{mission_id}?fleet_id=… (both require missions:write), or in the Fleet Manager web app.

Related

• Operations
• Robots
• Telemetry