Transport and authentication
POST /api/v1/<capability-id> uses JSON for reads and writes. With sign-in enabled, the application session and an Origin matching the configured application origin are required. The server resolves the company and user. Never copy cookies or spoof Origin to build an integration.
Request and response
The request has input plus optional expectedVersion and idempotencyKey. Optimistic commands require the appropriate entity version; retry-safe commands require a key. Success returns a result property. Failure returns error.code and optional error.params. Responses use Cache-Control: no-store.
Read examples
project.list takes empty input. estimate.view takes a projectId UUID and still checks role/company access. These are internal capability identifiers, not public agent tools. The current UI adapter resolves channel ui on the server.
Retry and conflict handling
Retain the exact prepared payload, version and key for an uncertain idempotent retry. A changed decision is a new operation after reconciliation. version_conflict requires re-reading and review; idempotency_key_reused indicates different input reused a key. Not every command is retry-safe.
Contract limits
There is no published external compatibility, pagination, rate-limit, webhook or output-schema contract. Decimal server calculations remain authoritative. Capability version, entity version and the v1 route prefix have different meanings. A future public release must document them separately.
POST /api/v1/project.list
Content-Type: application/json
{
"input": {}
}