Hanzo
Start

Store

KV round-trip — create a store, read it back, delete it.

KV round-trip — create a store, read it back, delete it.

The delete belongs in the language's finally/defer, so a failed read still cleans up instead of leaving the store for the next run to collide with. This is the provisioning plane, and it is here because it is the one that answers. The value plane (/v1/kv/keys/{key} — kv_setKey, kv_getKey, kv_deleteKey) is authored in kv/openapi.yaml and is mounted nowhere.

The discriminator, since a 404 body alone proves nothing: auth middleware runs BEFORE the handler, so a route that EXISTS refuses with 403 and a route that does not is 404/405. /v1/kv, /v1/kv/demo, /v1/kv/keys and the control /v1/agents/{ref} all answer 403 "X-Org-Id required"; /v1/kv/keys/x answers 404. The parent collection routes and the child does not — which is the shape of a plane that was authored and never mounted, not of a key that is merely absent.

Provision a key-value resource

POST /v1/kv · reference →

ParameterInRequiredDescription
instancebody
namebody
hanzo kv create

GetKV returns one Hanzo KV store's metadata.

GET /v1/kv/{name} · reference →

GetKV returns one Hanzo KV store's metadata. It carries the store's status, its instance address and the Valkey user it authenticates as ("default", the only user a requirepass instance has) — never the password. A still-booting instance reads "provisioning", reconciled from the operator's live view.

ParameterInRequiredDescription
namepathyesThe user-supplied resource name (slug). Lowercased and trimmed server-side; must match `^[a-z0-9]([a-z0-9-]{0,
hanzo kv get <name>

DropKV deprovisions one Hanzo KV store.

DELETE /v1/kv/{name} · reference →

DropKV deprovisions one Hanzo KV store. It reverts any app instance bound to it back to Base BEFORE tearing down the org's dedicated Valkey instance, then deletes the sealed credential and removes the metadata row. Answers 204 with no body; a second call is a 404.

ParameterInRequiredDescription
namepathyesThe user-supplied resource name (slug). Lowercased and trimmed server-side; must match `^[a-z0-9]([a-z0-9-]{0,
hanzo kv rm <name>

Every command, call and tool above is generated from the same OpenAPI document that generates the SDKs themselves — the four surfaces are projections of one doc comment, so they cannot disagree.

How is this guide?

On this page