The write API: drive the review queue over HTTP
The control plane gets its first write surface — the unified review queue, list and decide, on tenant Bearer tokens that resolve into the same permission model as a human.
Tenant API tokens gave an app or a client integration a
credential that resolves into an authz principal. This release puts the first write surface on
top of it: the unified review queue, drivable over HTTP (v1.33).
Two endpoints, every kind of run
Skills awaiting approval, paused workflows, and missions awaiting review have always shared one queue in the dashboard. Now that queue is an API — so an external inbox, a Slack bot, or FirstHQ's approval screen can drive it without knowing which kind of run it's acting on:
# What needs a human?
curl -H "Authorization: Bearer $VOCION_TOKEN" https://your-install/api/v1/reviews
# → { "reviews": [ { "kind": "mission", "id": 42, "title": "Weekly PPC report — Daylyte", … } ] }
# Approve it
curl -X POST -H "Authorization: Bearer $VOCION_TOKEN" -H "Content-Type: application/json" \
-d '{"kind":"mission","id":42,"action":"approve","reason":"Numbers check out"}' \
https://your-install/api/v1/reviews/decide
# → { "ok": true, "reviews": [ /* what's still pending */ ] }
decide dispatches to the owning service — resume or cancel the workflow or mission, approve or reject
the skill run — and returns the refreshed queue so the caller's view stays in sync.
Authentication and authorization are one path
The point isn't the endpoints — it's that they go through the same door as everything else. The
Bearer token resolves to a principal, and deciding a review is the approve capability. An owner
or client-reviewer token holds it; a draft-only specialist token is rejected with 403 before
anything dispatches. The reviewer recorded on the run is token:<id>, so the audit trail shows exactly
which credential acted.
There's no separate "service account" authorization model to keep in sync with the human one. A token mutation and a human click are governed identically. That's what makes it a control plane rather than a pile of endpoints — see the API reference and the runs + reviews spec.
Why now
This is what FirstHQ and our reference deployments need to stand up: an app that isn't the Vocion dashboard, driving real work and routing approvals to the right human over a stable, authorized contract. MCP-over-HTTP (the agent/tool plane) is next; together they complete the control plane — see the API overview.