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
- Open Profile → AgentsGo to your profile. Keys belong to the workspace that is active when you create them.
- Pick the least access that worksMost CI jobs need Deploy. A status badge or dashboard needs only Read.
- Set an expiry30 days, 90 days, 1 year, or never. Expired keys are refused everywhere.
- 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.
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.
| Method | Path | Needs | What it does |
|---|---|---|---|
GET | /api/applications | read | Apps in the key's workspace, each with its latest Production release. |
GET | /api/applications/:id/status?environment=production | read | Current release status for an environment. |
GET | /api/applications/:id/logs?environment=production | read | Recent build and runtime logs. Add deploymentId=… for one release. |
GET | /api/applications/:id/rollback-targets?environment=production | read | Earlier healthy releases you can restore. |
GET | /api/applications/:id/deploy?environment=production | read | The latest deployment job for an environment. |
POST | /api/applications/:id/deploy?environment=production | deploy | Body {"action": "deploy"} (default), "redeploy", "retry", "cancel", or "rollback" with "deploymentId". |
GET | /api/applications/:id/environments/:env/variables | read | Variable names and scopes. Values are write-only and never returned. |
PUT | /api/applications/:id/environments/:env/variables | deploy | Body {"key": "NAME", "value": "…"} sets one variable. |
POST | /api/applications/:id/environments/:env/variables | deploy | Imports a .env file sent as text/plain. Add ?replace=1 to overwrite existing names. |
DELETE | /api/applications/:id/environments/:env/variables | deploy | Body {"key": "NAME"} removes one variable. |
Deploy from CI
Store a Deploy key as AOZUMI_TOKEN and the app id as AOZUMI_APP, then:
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 .