Authentication

Every request uses one header: Authorization: Bearer. For a credential, join its Access Key and Secret Key with a colon. Create credentials from the Credentials page in the console.

curl https://api.justdeploy.net/ping \
  -H "Authorization: Bearer YOUR_ACCESS_KEY:YOUR_SECRET_KEY"

The older X-Access-Key and X-Secret-Key headers still work, so an app already running on them keeps working and needs no new build. Use the single header for anything new.

"pong"

AI tools connected through MCP send the same header with a different token: a user-scoped one issued during the MCP sign-in, with no colon in it. Your MCP client handles this automatically, so there is nothing to create or paste, and the token covers every organization you belong to.

{
  "organizations": [
    {
      "id": "org_...",
      "name": "My Organization",
      "role": null
    }
  ]
}

What a key is allowed to do

Every key carries a scope, and the API enforces it. Credentials you create in the console, and the one printed in DEPLOY.md, use deploy scope. Deploy-scope keys can use the full JustDeploy API for that organization. Keys issued for an app to use at runtime are deliberately narrower.

• Deploy scope: the whole API, builds, guides, tables, environment variables, firewall rules, schedulers, logs, metrics, and issuing runtime keys.
• Runtime scope: what an app needs and nothing more, read and write database rows, upload and download files, list databases and storages, and read its own project’s environment variables and firewall rules. It cannot change tables, write environment variables, start builds, fetch guides, or issue keys.

A runtime key is bound to the project it was issued for. Using it against a different project returns 403, even inside the same organization.

A deploy key printed in a project’s DEPLOY.md is bound to that project too: management calls against any other project return 403, while database, storage, and email stay organization-wide. The key from the organization DEPLOY.md remains organization-wide.

A project can also be restricted to managing members, a console setting on the project’s page. On such a project, creating a build, rebuilding, and redeploying return 403 with a message naming the managers, unless the caller is one of them. Roles carry no weight here: an organization-wide credential is always refused, whoever issued it, and a signed-in user or MCP token passes only if that user is picked, owner or not. Retrying with the same credential cannot succeed; use that project’s own DEPLOY.md, or act as a managing member. The setting itself can be changed by any member, but only in the console.

Issuing a key for your app

Requires a deploy-scope key or a Bearer token. Check the project’s environment variables first. If a key is already registered, reuse it rather than issuing another.

{
  "credential": {
    "id": 12,
    "access": "ak_...",
    "secret": "sk_...",
    "description": "Runtime key for project prj_...",
    "expiredAt": null,
    "createdAt": "2026-07-27T00:00:00.000Z"
  }
}