List jobs
Authorization
api_key jobs:readAn atk_-prefixed API key, created under Settings → API keys.
In: header
Scope: jobs:read
Response Body
application/json
application/json
curl -X GET "https://example.com/v1/jobs"[ { "agent_id": "2b1e3b65-2c04-4fa2-a2d7-467901e98978", "created_at": "2019-08-24T14:15:22Z", "description": "string", "failure_reason": "string", "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "last_activity": "string", "planning": true, "primary_session_id": "5fb6eee6-42c6-4a4c-8ea0-dd0a7a8d08e5", "project_id": "405d8375-3514-403b-8c43-83ae74cfe0e9", "state": "string", "title": "string", "updated_at": "2019-08-24T14:15:22Z" }]Subscribe to account events GET
A live server-sent-event stream of everything happening in the account: artifacts appearing, jobs changing state, chats finishing, kanban card runs settling. This is the intended way to wait for dispatched work rather than polling. Each frame is a JSON object with a `type` discriminator and the new state inline — there is no need to re-read the resource to learn what changed. **The stream is not replayable.** It carries no event ids and ignores `Last-Event-ID`; anything produced while you were disconnected is not redelivered. On reconnect, re-read whatever you care about (`GET /v1/jobs`, `GET /v1/sessions/{id}/artifacts`) and carry on from there. Treat it as a latency optimization over polling, not as a durable log.
Dispatch a job POST
Creates a job and starts an agent working on it immediately. Returns as soon as the work is queued — the returned job reads `backlog` with a placeholder title, both of which change within moments. Watch it finish on `GET /v1/events` (`job.state_changed`), or poll `GET /v1/jobs/{job_id}`. Terminal states are `done`, `failed`, and `ambiguous` — the last meaning the agent needs something from you, which you answer by posting to the job's `primary_session_id`.