API Reference

Priiism gives you programmatic access to your projects through two surfaces that share one credential — a vk_ API key:

• REST — the same-origin /api/* HTTP surface, for reads and scripting.
• MCP — a network-reachable Model Context Protocol endpoint at /api/mcp/v1, for connecting an AI client (such as Cursor and other MCP-compatible tools) to your project. See the MCP Quickstart.

There is no separate API domain. Every request goes to the same host that serves your dashboard.

Authentication

Create a key under Account Settings → Developer, then send it as a Bearer token on the Authorization header. Keys look like vk_live_... — see Authentication for the full key lifecycle and Scopes for what a key is allowed to do.

curl -H "Authorization: Bearer vk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  https://YOUR-APP-HOST/api/projects

Replace YOUR-APP-HOST with the host you use to reach your dashboard, and the placeholder key with your own. A key’s secret is shown in full exactly once, at creation time, and can never be retrieved again.

Base path

All REST endpoints are served under /api/ on the same origin as your dashboard. Paths below are written relative to that origin. [id] is a project id; [keyId] is an API-key id.

Endpoints

Every path below corresponds to a real route.

Projects

Method	Path	Description
GET	/api/projects	List projects in your organization
GET	/api/projects/[id]	Get a single project

Deployments

Method	Path	Description
GET	/api/projects/[id]/deploy	List recent deployments and their status
POST	/api/projects/[id]/deploy	Trigger a deployment

Environment variables

Method	Path	Description
GET	/api/projects/[id]/env	List environment variables
POST	/api/projects/[id]/env	Create or update an environment variable
DELETE	/api/projects/[id]/env	Remove an environment variable

API keys

Key management itself lives under /api/keys. Creating, revoking, and re-scoping keys is done from the dashboard while you are signed in (see Authentication); listing is available to a key with read access.

Method	Path	Description
GET	/api/keys	List your organization’s keys (metadata only — never the secret)
POST	/api/keys	Mint a new key
PATCH	/api/keys/[keyId]	Rename or re-scope a key
DELETE	/api/keys/[keyId]	Revoke a key

Reads vs. actions. Read requests (GET) are available to any valid key. Actions that change a project — deploying, setting environment variables, working with source control — are authorized per-scope and are most conveniently driven through the MCP tool surface, which maps each capability to the scopes your key holds.

Errors

Errors use a small JSON envelope. The status code tells you the category; the error field is a stable machine-readable code.

401 — bad key

A missing, unknown, revoked, or expired key returns 401. The response body is deliberately generic and does not reveal which of those it was:

{ "error": "invalid_api_key" }

If the Authorization header is present but is not a well-formed Bearer vk_... token, you get 422 instead:

{ "error": "malformed_authorization" }

403 — insufficient scope

A valid key that lacks the scope required for the operation (or a project-scoped key reaching for a different project) returns 403. This is how you tell “bad key” (401) apart from “key is fine, but not allowed to do this” (403):

{
  "error": "insufficient_scope",
  "message": "This operation is not available for this key.",
  "requiredScope": "deploy"
}

When you hit a 403, check Scopes and re-scope the key (or issue a new one) with the capability you need. The requiredScope field, when present, names the missing capability.

Next steps

• Authentication — create, reveal-once, revoke, and expire keys; org-wide vs. project-scoped keys.
• MCP Quickstart — connect an AI client to your project.
• Scopes — role bundles and granular capabilities.