Developers
K2 Server API
Every K2 server exposes an HTTP API over its own your-name.k2.dev subdomain: message your agents, spawn fresh live agent sessions in any workspace, and read their answers back — from CI, from your own apps, from anywhere. The agent working the session replies with k2 respond; you read the conversation with a plain GET.
The API is agent-agnostic: workspaces configured for Claude Code, Codex, Gemini, Grok, Pi, Cursor, Hermes, or your own custom agent all speak the same endpoints. See the K2 agent contract for what a custom agent needs to participate.
K2_API=1), reachable through a Pro subdomain — API calls over the tunnel are a Pro feature. Host-session listing/resume needs v0.40.30; the message API works on earlier 0.40.2x servers too.Authentication
Create an API key on the server (K2 app → Settings → API Keys, or over the owner CLI). Keys look like k2sk_… and are shown once at creation — K2 stores only a hash. Present the key on every request; the Authorization header is preferred (keeps it out of URLs and logs), ?token= works as a curl fallback.
curl https://your-name.k2.dev/v1/ping \
-H "Authorization: Bearer k2sk_XXXXXXXXXXXXXXXXXXXX"Capability discovery
/v1/pingLiveness plus what this server has enabled — probe this first and feature-gate your client on it.
{
"ok": true,
"api": {
"enabled": true,
"hostSessions": true, // spawn/list/resume live agent sessions
"sandboxes": "none" // "microvm" on Dedicated servers
}
}Message a workspace's agent
/v1/w/<workspace>/messageDeliver a message into the workspace's canonical agent session (the same session you see in the app), waking it if needed. <workspace> is the workspace name as shown in K2.
curl -X POST https://your-name.k2.dev/v1/w/my-project/message \
-H "Authorization: Bearer k2sk_..." \
-H "Content-Type: application/json" \
-d '{"message": "Summarize today's failing tests."}'Host sessions — spawn agents that answer back
Host sessions are fresh, API-owned agent sessions: each spawn boots the workspace's configured agent in a real terminal, briefs it that an API caller is listening, and gives it a private scoped token so its k2 respond output lands in your conversation — and only yours. One session is one conversation; for concurrent requests, spawn concurrent sessions.
/v1/w/<workspace>/host-sessionsSpawn a session with an initial prompt. Pass "session"with a previously returned id to resume that conversation instead — if it's still live the message is delivered into the running agent (no double-boot); if it has exited, the agent is relaunched resuming the same conversation.
// request
{ "prompt": "Run the test suite and report failures." }
// 200 — fresh spawn
{
"sessionId": "6f0c9a52-…",
"agentName": "api-20260707-…",
"workspace": "my-project",
"sandbox": "none",
"stream": { "grid": "/cli/sessions/grid?session=…&token=k2st_…" }
}
// 200 — resume of a still-live session
{ "sessionId": "6f0c9a52-…", "delivered": true, "live": true }By default the agent runs with its auto-approve flags stripped — an unattended server never bypasses permission prompts just because a request came in over the wire. Opt a workspace in deliberately with the api_skip_permissions workspace setting.
/v1/w/<workspace>/host-sessionsList this workspace's API-spawned sessions.
{
"workspace": "my-project",
"sessions": [
{ "sessionId": "6f0c9a52-…", "agentName": "api-…", "live": true, "lastSeenAt": "…" }
]
}/v1/w/<workspace>/host-sessions/<id>Send a follow-up message into a live session's terminal.
// request
{ "message": "Now fix the first failure." }
// 200
{ "sessionId": "6f0c9a52-…", "delivered": true, "live": true }/v1/w/<workspace>/host-sessions/<id>/messages?since=<seq>Read the agent's replies. seq is monotonic per session and reads are non-destructive — keep your last latest_seq as a cursor and poll. Entries with "final": true are the agent's k2 respond --final answers.
{
"messages": [
{ "seq": 1, "text": "3 tests failing in auth.rs — details follow.", "ts": 1783460000, "final": false },
{ "seq": 2, "text": "Fixed. All 214 tests pass.", "ts": 1783460420, "final": true }
],
"latest_seq": 2
}Errors
Unknown workspaces, unknown sessions, and things you're not allowed to see are indistinguishable by design — all return the same 404 body, so the API never confirms what exists. Malformed requests return 400 with a plain error string; session-spawn quotas return 429 with an error and code.
404 { "error": "no such workspace" }Sandboxes (Dedicated)
Dedicated servers add a hardened microVM sandbox API — the same session model, but each agent boots inside its own isolated Linux virtual machine, built for untrusted workloads and agent fleets. Capability shows as "sandboxes": "microvm" on /v1/ping. Full sandbox documentation ships alongside Dedicated availability.