Subako Public API
The public HTTP interface to Subako.
Version v1
Base URL
https://api.us.cloud.subako.aiagents
- GET/v1/agents
- POST/v1/agents
- GET/v1/agents/{agent_id}
- DELETE/v1/agents/{agent_id}
- PATCH/v1/agents/{agent_id}
- GET/v1/agents/{agent_id}/security
- PUT/v1/agents/{agent_id}/security
- GET/v1/agents/{agent_id}/versions
- POST/v1/agents/{agent_id}/versions
api-keys
me
model-providers
- GET/v1/model-providers
- POST/v1/model-providers
- GET/v1/model-providers/{model_provider_id}
- DELETE/v1/model-providers/{model_provider_id}
- PATCH/v1/model-providers/{model_provider_id}
organization
- GET/v1/organization
- PATCH/v1/organization
- GET/v1/organization/credits
- GET/v1/organization/invitations
- POST/v1/organization/invitations
- DELETE/v1/organization/invitations/{invitation_id}
- GET/v1/organization/members
- PUT/v1/organization/members/{user_id}
- DELETE/v1/organization/members/{user_id}
- GET/v1/organization/usage
sessions
- GET/v1/sessions
- POST/v1/sessions
- GET/v1/sessions/{session_id}
- DELETE/v1/sessions/{session_id}
- POST/v1/sessions/{session_id}/approvals/{call_id}
- POST/v1/sessions/{session_id}/cancel
- GET/v1/sessions/{session_id}/events
- POST/v1/sessions/{session_id}/events
- GETThe same log as a live tail, framed as SSE: one event per row, `id` the seq, `event` the wire `type`, `data` the same [`SessionEventBody`] the paged read renders. The stream stays open across idle stretches -- a keep-alive comment holds the connection while nothing happens -- so one connection spans a session's whole life rather than a single run. With no position named it starts at the live head, fixed before the response begins; a client that wants history pages `/events` newest-first and deduplicates on seq against what the tail delivers. An initial id-only frame establishes the reconnect cursor without dispatching a message. Continuity before that frame is received requires an explicit `after_seq`.
/v1/sessions/{session_id}/events/stream - POST/v1/sessions/{session_id}/tokens
clients
- POST/v1/sessions/{session_id}/clients
- DELETE/v1/sessions/{session_id}/clients/{client_id}
- POST/v1/sessions/{session_id}/clients/{client_id}/calls/{call_id}/ack
- POSTAnswers 204 where [`ack_client_call`] answers the appended row, because settling a call appends nothing of its own. The content goes onto the call's row and reaches the log as the `tool_result` the engine journals once the broker hands the answer over, so core appending one here would make two writers for the same event.
/v1/sessions/{session_id}/clients/{client_id}/calls/{call_id}/result - POSTUse a new key for each heartbeat. Reusing one returns the saved expiration without extending the registration again.
/v1/sessions/{session_id}/clients/{client_id}/ping - PUT/v1/sessions/{session_id}/clients/{client_id}/tools
skills
- GET/v1/skills
- POST/v1/skills
- GET/v1/skills/{skill_id}
- DELETE/v1/skills/{skill_id}
- PATCH/v1/skills/{skill_id}
- GET/v1/skills/{skill_id}/versions
- POST/v1/skills/{skill_id}/versions
vaults
- GET/v1/vaults
- POST/v1/vaults
- GET/v1/vaults/{vault_id}
- DELETE/v1/vaults/{vault_id}
- PATCH/v1/vaults/{vault_id}
- GET/v1/vaults/{vault_id}/credentials
- POST/v1/vaults/{vault_id}/credentials
- DELETE/v1/vaults/{vault_id}/credentials/{credential_id}
workspaces
- GET/v1/workspaces
- POST/v1/workspaces
- GET/v1/workspaces/{workspace_id}
- DELETE/v1/workspaces/{workspace_id}
- PATCH/v1/workspaces/{workspace_id}
- GET/v1/workspaces/{workspace_id}/members
- POST/v1/workspaces/{workspace_id}/members
- PUT/v1/workspaces/{workspace_id}/members/{user_id}
- DELETE/v1/workspaces/{workspace_id}/members/{user_id}
- GET/v1/workspaces/{workspace_id}/usage