Skip to content
Docs

REST API and API keys

Everything a CI job needs, over plain HTTPS with a key you can scope, expire and revoke. For AI agents, the same keys work with the MCP endpoint.

Create a key

  1. Open Profile → AgentsGo to your profile. Keys belong to the workspace that is active when you create them.
  2. Pick the least access that worksMost CI jobs need Deploy. A status badge or dashboard needs only Read.
  3. Set an expiry30 days, 90 days, 1 year, or never. Expired keys are refused everywhere.
  4. Copy it nowAozumi shows a key once and stores only a hash. Keys start with slt_.

Access levels

A key acts as you, only in its workspace, and never beyond its access level or your own role.

  • Read: like a viewer. See apps, status, logs, rollback targets and variable names.
  • Deploy: like a builder. Also deploy, retry, cancel, roll back, create apps from the CLI, and set or remove variables.
  • Manage: like an admin for apps. Also create share links and change app settings and sharing.

On the REST API, every endpoint below needs Read or Deploy, so Manage adds nothing there yet. It matters for agents (the MCP share tool) and for the CLI (changing who can open an app).

No key can add or remove members or change workspace settings.

Authenticate

Send the key as a bearer token. Requests without one use your browser session as usual.

Terminal
curl -H "Authorization: Bearer $AOZUMI_TOKEN" https://aozumi.dev/api/applications

Endpoints

Only these routes accept API keys. :id is an application id from GET /api/applications; environment defaults to production.

MethodPathNeedsWhat it does
GET/api/applicationsreadApps in the key's workspace, each with its latest Production release.
GET/api/applications/:id/status?environment=productionreadCurrent release status for an environment.
GET/api/applications/:id/logs?environment=productionreadRecent build and runtime logs. Add deploymentId=… for one release.
GET/api/applications/:id/rollback-targets?environment=productionreadEarlier healthy releases you can restore.
GET/api/applications/:id/deploy?environment=productionreadThe latest deployment job for an environment.
POST/api/applications/:id/deploy?environment=productiondeployBody {"action": "deploy"} (default), "redeploy", "retry", "cancel", or "rollback" with "deploymentId".
GET/api/applications/:id/environments/:env/variablesreadVariable names and scopes. Values are write-only and never returned.
PUT/api/applications/:id/environments/:env/variablesdeployBody {"key": "NAME", "value": "…"} sets one variable.
POST/api/applications/:id/environments/:env/variablesdeployImports a .env file sent as text/plain. Add ?replace=1 to overwrite existing names.
DELETE/api/applications/:id/environments/:env/variablesdeployBody {"key": "NAME"} removes one variable.

Deploy from CI

Store a Deploy key as AOZUMI_TOKEN and the app id as AOZUMI_APP, then:

Terminal
curl -fsS -X POST \
  -H "Authorization: Bearer $AOZUMI_TOKEN" \
  -H "content-type: application/json" \
  -d '{"action":"deploy"}' \
  https://aozumi.dev/api/applications/$AOZUMI_APP/deploy

# Then poll until the release is live or failed
curl -fsS -H "Authorization: Bearer $AOZUMI_TOKEN" \
  https://aozumi.dev/api/applications/$AOZUMI_APP/status

Errors

  • 401: the key is invalid, expired, revoked, a CLI login key, or an older agent key without an access level.
  • 403: the key's access level (or your role) does not allow this action.
  • 404: the app does not exist in the key's workspace. Apps in your other workspaces look missing on purpose.

Questions

What can a read key do?
List apps and read status, logs, rollback targets and environment variable names. It cannot deploy or change anything.
Can an API key add members or change workspace settings?
No. Keys never administer the workspace, whatever the role of the person who created them. Manage members and workspace settings in the console.
Do my older agent keys still work?
Yes, on MCP and the CLI exactly as before. They are not accepted by the REST API; create a new key with an access level for that.
What happens when the person who created a key leaves the workspace?
Their keys stop working immediately, because a personal key acts as that person in that workspace.

Checked against the product on .