Submit task
Submit a browser task to a device (202). Runs the write gate (scope + entitlement), loads the device
org-scoped and checks its Space, requires the device be active (terminated → 410, otherwise → 409
device_not_ready), claims the device’s single task slot (a held slot → 409 device_busy), and
persists a running task the worker driver then drives to terminal. Idempotency-Key replays a
prior success and 409s a reused key with a different body.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Headers
At-most-once key for the submit
Path Parameters
Device id (dev_<uuid>)
Body
Response
The accepted task
A task as returned on the /v1 surface.
dev_<uuid> of the owning device.
task_<uuid>.
Discriminator for polymorphic SDK decoders. Always "task".
Why the task ended, as recorded when it was finalized: {"error": …, "detail": …} on a
failure, the agent's answer on a success. null while still running.
This is on the wire because the alternative was observed and is indefensible: a task that
reports status: "failed" and nothing else. The reason already existed in the record —
finalize_terminal writes it — and withholding it from the caller left them with a failure
they could not act on, or even describe. Details here are fixed, non-leaking strings; the
underlying transport error is logged and never persisted.