---
title: "Read Mission Request"
method: GET
path: "/api/v1/mission-requests/{request_id}"
tags: ["mission requests"]
---

# Read Mission Request

`GET /api/v1/mission-requests/{request_id}`

## Request

- Base URL: `https://api.brumby.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.brumby.com/api/v1/mission-requests/{request_id}`
- Auth: HTTP bearer

One request with its mission, and once launched, what the dock and aircraft did.

## Path parameters

- `request_id` string, uuid, required

## Response `200`

Successful Response

- MissionRequestDetail: One request, with its mission and, once launched, what became of it. The feed omits `config`: a cross-farm list must not hand a reader another farm's paddock geometry. A pilot who has opened one request needs the mission to judge it, and the request keeps it -- the action discards its copy on the dock's first ack.
  - `execution_type` 'deployment' | 'hitl' | 'sitl'
  - `simulation` object, nullable
  - `request_id` string, uuid, required
  - `purpose` 'commercial' | 'testing'
  - `execution_profile` string, nullable
  - `origin` string, nullable
  - `readiness` string, nullable
  - `schema_version` string, nullable
  - `farm_id` string, required
  - `device_id` string, nullable, required
  - `mission_id` string, required
  - `mission_plan_id` string, uuid, nullable
  - `mission_plan_revision` integer, nullable
  - `config_sha256` string, required
  - `state` string, required
  - `requested_for` string, date-time, nullable, required
  - `requested_at` string, date-time, required
  - `requested_by` string, required
  - `action_id` string, uuid, nullable, required
  - `decided_at` string, date-time, nullable, required
  - `decided_by` string, nullable, required
  - `decision_note` string, nullable, required
  - `config_check` MissionConfigCheck, required: What the dock would find missing or invalid in the config as asked.
    - `ok` boolean, required
    - `missing` string[], required
    - `invalid` string[], required
  - `preparation_config_check` MissionConfigCheck, required: What the dock would find missing or invalid in the config as asked.
    - `ok` boolean, required
    - `missing` string[], required
    - `invalid` string[], required
  - `flight_record_id` string, uuid, nullable, required
  - `stage_failed` boolean, required
  - `preflight_overrides` LaunchOverrideRecord[], nullable
    - `check` string, required
    - `reason` string, required
    - `by` string, required
    - `at` string, date-time, required
  - `dock_position` DockPositionView: Where the launching dock says it is, and what is wrong with that. `services/dock_position`. `position` is `{latitude, longitude}` as the dock reported it whatever its provenance or age, so a pilot can be shown what an override would stamp. A dock that has reported none has `overridable` false and no reason unlocks it: the aircraft refuses a mission with no `base_stations[0]`, so there would be nothing to fly.
    - `position` object, nullable, required
    - `simulated` boolean, required
    - `stale` boolean, required
    - `age_s` number, nullable, required
    - `overridable` boolean, required
    - `source` string, nullable
    - `line` string, nullable
  - `dock_aircraft` DockAircraftCheckView: Whether the aircraft's own fix agrees with the dock position LAUNCH would stamp. `services/dock_aircraft_position`, computed on read without any pilot override. `state` is `ok`, `mismatch`, `no_aircraft_position` (refuses: no fresh 3D aircraft fix), or `not_checked` (no dock position to compare, or a simulated aircraft that is not publishing one). `detail` is the pilot's sentence when it refuses.
    - `state` 'ok' | 'mismatch' | 'no_aircraft_position' | 'not_checked', required
    - `distance_m` number, nullable, required
    - `max_distance_m` number, required
    - `detail` string, nullable, required
    - `overridable` boolean, required
  - `preparation` MissionPreparation, required
    - `state` 'needs_preparation' | 'awaiting_signoff' | 'ready' | 'invalidated' | 'active' | 'complete', required
    - `reason` string, nullable
    - `record_id` string, uuid, nullable
    - `prepared_at` string, date-time, nullable
    - `prepared_by` string, nullable
  - `rig_manifest` object, nullable
  - `config` object, required
  - `build_report` object, nullable
  - `disposition` MissionDispositionResponse: What became of one staged mission, in terms a farmer can be told. Derived, never stored (`services/mission_disposition`). `reason` is a sentence for a person and is never null on a negative disposition.
    - `schema_version` '1'
    - `action_id` string, uuid, required
    - `device_id` string, required
    - `mission_id` string, required
    - `farm_id` string, required
    - `disposition` 'pending' | 'staged' | 'launched' | 'flown' | 'refused' | 'superseded' | 'expired', required
    - `reason` string, nullable, required
    - `staging` MissionConfigStatusResponse, required
      - `action_id` string, uuid, required
      - `device_id` string, required
      - `mission_id` string, required
      - `state` 'pending' | 'publishing' | 'accepted' | 'completed' | 'failed' | 'rejected' | 'expired', required: FleetOps-side lifecycle of one diagnostic action.
      - `result_status` 'accepted' | 'completed' | 'failed' | 'rejected', required: Device-reported status on the wire.
      - `staged` boolean, nullable, required
      - `config_sha256` string, required
      - `reported_config_sha256` string, nullable, required
      - `sha_verified` boolean, nullable, required
      - `detail` string, nullable, required
      - `issued_at` string, date-time, required
      - `expires_at` string, date-time, required
      - `accepted_at` string, date-time, nullable, required
      - `result_received_at` string, date-time, nullable, required
      - `created_at` string, date-time, required
    - `approval` MissionApprovalEvidence, required: Who launched the mission request, and the signed JSA it was launched under.
      - `request_id` string, uuid, required
      - `launched_at` string, date-time, required
      - `launched_by` string, nullable, required
      - `record_id` string, uuid, nullable, required
      - `signed_at` string, date-time, nullable, required
      - `signed_by` string, nullable, required
    - `flight` MissionFlightEvidence, required: The materialized flight FleetOps observed after the launch was authorised. `outcome` is the dock-observed one, `unknown` included: see `FlightOutcome`. A customer that renders "completed" for an unobserved ending is inventing an answer FleetOps deliberately refused to invent.
      - `flight_id` string, uuid, required
      - `started_at` string, date-time, required
      - `ended_at` string, date-time, nullable, required
      - `outcome` 'in_progress' | 'completed' | 'recalled' | 'interrupted' | 'unknown' | 'sim_ended', required: How a materialized flight ended. ``unknown`` is honest, not lazy: operations went stale mid-flight, so the dock-side truth was never observed. ``interrupted`` is a dock reboot while the flight row was open. ``sim_ended`` is a SIMULATED flight whose simulation was ended -- by the operator, a failure, or a runner that stopped reporting -- while the flight was open: the aircraft did not land, it stopped existing, and saying "completed" or "unknown" would each be a lie of a different kind. Only `services/sim_runs.close_out` writes it. No migration: `enum_type` is a plain String(20).
      - `end_reason` string, nullable, required
  - `stage` MissionStageResponse: Where one request is right now, for the pilot console. Derived, never stored (`services/mission_stage`). `reason` is a sentence for a person and names the thing being waited on; `since` is when this stage began, when that is known.
    - `schema_version` '1'
    - `request_id` string, uuid, required
    - `device_id` string, nullable, required
    - `stage` 'awaiting_pilot' | 'transferring' | 'dock_opening' | 'waiting_for_controller' | 'takeoff' | 'flying' | 'returning' | 'landed' | 'upload_authorized' | 'uploading' | 'upload_complete' | 'closed' | 'unknown', required
    - `reason` string, required
    - `since` string, date-time, nullable, required
    - `evidence` MissionStageEvidence, required: The facts the stage was read from, so a pilot can see WHY without a log search. Every field is nullable: absent evidence is reported as absent, never invented.
      - `simulation_profile` string, nullable
      - `loaded_mission` LoadedMission
        - `observed_at` string, date-time, required
        - `mission_id` string, nullable
        - `request_id` string, nullable
        - `config_sha256` string, required
        - `controller` 'sitl-bench-stub-v1', required
        - `simulation_session_id` string, nullable
      - `loaded_config_matches` boolean, nullable
      - `request_state` string, required
      - `action_state` string, nullable, required
      - `delivered` boolean, nullable, required
      - `config_sha256` string, nullable, required
      - `dock_state` string, nullable, required
      - `dock_state_since` string, nullable, required
      - `dock_report_age_s` number, nullable, required
      - `dock_stale` boolean, nullable, required
      - `launch_holds` string[], required
      - `recall` object, nullable, required
      - `armed` boolean, nullable, required
      - `fcu_mode` string, nullable, required
      - `altitude_m` number, nullable, required
      - `telemetry_age_s` number, nullable, required
      - `telemetry_stale` boolean, nullable, required
      - `flight` MissionFlightEvidence, required: The materialized flight FleetOps observed after the launch was authorised. `outcome` is the dock-observed one, `unknown` included: see `FlightOutcome`. A customer that renders "completed" for an unobserved ending is inventing an answer FleetOps deliberately refused to invent.
        - `flight_id` string, uuid, required
        - `started_at` string, date-time, required
        - `ended_at` string, date-time, nullable, required
        - `outcome` 'in_progress' | 'completed' | 'recalled' | 'interrupted' | 'unknown' | 'sim_ended', required: How a materialized flight ended. ``unknown`` is honest, not lazy: operations went stale mid-flight, so the dock-side truth was never observed. ``interrupted`` is a dock reboot while the flight row was open. ``sim_ended`` is a SIMULATED flight whose simulation was ended -- by the operator, a failure, or a runner that stopped reporting -- while the flight was open: the aircraft did not land, it stopped existing, and saying "completed" or "unknown" would each be a lie of a different kind. Only `services/sim_runs.close_out` writes it. No migration: `enum_type` is a plain String(20).
        - `end_reason` string, nullable, required
      - `upload_run_id` string, nullable, required
      - `upload_granted_at` string, date-time, nullable, required
      - `upload_objects_expected` integer, nullable
      - `upload_objects_received` integer, nullable
      - `upload_progress_state` string, nullable
      - `upload_completion_reported` boolean, nullable
      - `dock_verification` 'not_reported_to_fleetops'
      - `storage_cleared` 'not_reported_to_fleetops'

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/brumby/apis/brumby-platform-api.md) - [All operations](https://skmtc.dev/brumby/apis/brumby-platform-api/llms.txt) - [OpenAPI document](https://skmtc.dev/brumby/apis/brumby-platform-api/revisions/fe185e20813e?raw)