---
title: "V4 Missions Stream"
method: GET
path: "/v4/missions/stream"
---

# V4 Missions Stream

`GET /v4/missions/stream`

## Request

- Base URL: `https://api.signalpipe.io` (the document declares no server; this is the origin it was published from)
- URL: `https://api.signalpipe.io/v4/missions/stream`
- Auth: none declared

SSE stream of send-ready missions for the authenticated tenant (§3.3, #23).

The v4 replacement for the sidecar's "poll /sync/missions for
status='approved' -> execute" loop: a user-side sender (daemon #25 / plugin
v2.0 #26) holds this stream open, sends each `mission_ready`, then acks via
/v4/missions/{id}/ack.

Named text/event-stream events:
  connected     once on open; carries the tenant's auto_threshold.
  mission_ready a mission to send (lean, send-only projection).
  heartbeat     every ~30s; keep-alive + reports pause (backoff) state.
  shutdown      server is stopping, or the token is no longer valid -> close.

THE AUTO-FIRE GATE LIVES HERE (the §3.3 SCOPE NOTE): a mission auto-fires
only when its 0-1 fused_score >= users.auto_threshold (default 1.01 =
manual). Enforced in _sse_poll (promotes pending -> approved). DELIVERY IS
AT-LEAST-ONCE: a reconnect re-emits any approved-but-unacked mission, so the
sender MUST dedupe per mission id (an ack flips status -> 'sent', which drops
it from the stream). Exactly-once (an emit-time 'dispatched' status + a
timeout re-drive) is a deliberate follow-up, out of scope for the
single-sender-per-tenant MVP.

## Headers

- `authorization` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/signalpipe/apis/mantidae-v3-0.md) · [All operations](https://skmtc.dev/signalpipe/apis/mantidae-v3-0/llms.txt) · [OpenAPI document](https://skmtc.dev/signalpipe/apis/mantidae-v3-0/revisions/14f89c374730?raw)