API reference
Agents API
Create and manage durable agent configurations.
Agent sessions API
Start, list, retain, archive, and detect conflicts for task sessions.
Agent turns API
Submit work, inspect results, cancel turns, and emit events.
Agent events API
Read and stream agent progress, widgets, and artifacts.
Agent templates API
Browse curated starting points for common agent workflows.
Agent preferences API
Read and update communication defaults and learning-mode settings.
Approval requests API
List and resolve human approval gates.
Repository change requests API
Review and accept agent-prepared repository changes.
Akua-Context header for broad credentials.
SDK shape
The generated SDK groups methods by OpenAPI operation ID, not by URL nesting. A TypeScript client should read naturally:Why flat paths
The API does not use/v1/agent/... or deeply nested paths. Flat resources make common workspace queries easier:
- List all running turns in a workspace.
- Show every pending approval request.
- Stream events for a session or turn.
- Render dashboard chat widgets from normalized events.
- Reuse a session when an ambient trigger continues existing work.
- Inspect repository change requests across agents to avoid duplicate work.
Protocol compatibility
Akua supports Agent Client Protocol as a compatibility adapter, not as a separate product data model. The ACP bridge maps session creation, prompts, streaming updates, and permission prompts to the sameagent_sessions, agent_turns, agent_events, and approval_requests resources.
Use the REST API when you need workspace-scoped management, SDK resources, list filters, audit history, quotas, billing controls, retention, or ambient agent configuration. Use ACP when an editor or agent client wants a standard interactive protocol for talking to an Akua-hosted agent.
ACP compatibility should not force Akua to copy protocol details before they stabilize. ACP currently centers on sessions, prompt turns, updates, tool calls, plans, permissions, and capability negotiation. Multi-agent and forked-session work is still evolving, so Akua keeps canonical lineage in its own resources and maps to ACP where a client supports it.
The bridge is intentionally stateless. It does not create ACP-only canonical rows, ACP IDs, or a separate approval table. Unknown ACP features are ignored when they are advisory, or represented as agent_events artifacts when the information should remain visible in the dashboard and event stream.
Zed’s external-agent model is a useful comparison. Zed uses ACP to connect external agents to the editor UI, but external agents still keep their own authentication, billing relationship, configuration files, and feature limits. Akua follows the same separation: ACP is an adapter for interactive agent clients, while Akua resources own workspace scope, approvals, repository change requests, quotas, retention, and audit history.
ACP permission prompts and Codex-style approvals are runtime gates. Akua maps them into approval_requests so they can be listed, audited, expired, and resolved from the dashboard or API. Repository change requests stay separate: they are durable change artifacts with diffs, validation, and review state. Accepting one can itself require an approval request when policy demands it.
Integration examples
Use the REST API or generated SDK for durable product integration. Use Code Mode/MCP when an agent needs to discover and call the Akua API as a tool. Use ACP when an editor or agent client already speaks the protocol and wants a standard interactive stream.Schema notes
Some fields are intentionally split so clients can distinguish preferences from policy-controlled results:
Widget events should be typed. A
widget.created event carries widget_type, schema_version, resource_refs, optional reactive_bindings, and actions. Initial widget types include approval_card, choice_card, status_card, navigation_hint, and repository_change_request_review.
Actions are prepared platform actions, not arbitrary client code. Reactive bindings let dashboard widgets stay current while API and ACP clients can ignore them or render their own equivalents.
Widgets may represent a whole interaction, not just one resource. For example, an agent can emit a card that combines a repository change request, an install status, a documentation link, and prepared reply buttons. Akua can also synthesize default widgets from canonical resources; resource state remains the source of truth.
V1 does not need a separate widget-action endpoint. Clients execute the underlying action through the canonical resource API, such as resolving an approval request, creating a turn, submitting structured input, running an attributed snippet action, or navigating to a dashboard path. Attributed snippet runs roll up to the source turn’s usage_summary.api_call_count.
Idempotency and state
Mutation requests that create work useIdempotency-Key so clients can safely retry interrupted requests. Mutable resources include etag and use If-Match when an update depends on the current state.
Clients should not set lifecycle state directly. Use resource actions such as cancel a turn, resolve an approval request, or archive a session.
Related topics
API authentication
Authenticate API clients and set workspace scope.
Agents API reference
Jump into the generated endpoint reference.
Platform MCP
Let external agents call the API through Code Mode.
Permissions and security
Understand grants, approvals, and audit events.