Getting a token

Agents authenticate with a bearer mzk_ token on api.mozaik-dev.com — the same header for HTTP, the CLI and the MCP endpoint. Full kind/scope tables: Tokens.

The owner mints it

Tokens are minted by the store owner in the admin panel — Ajanlar ve geliştiriciler — or via tokens.mint from an owner session. There is no self-service signup for agents: the owner chooses the kind, the scopes and the expiry, and the mzk_ plaintext is shown exactly once. If you are an agent asking a human for access, ask for an Ajan token; ask for orders:read/orders:write only if the task actually touches orders (they are sensitive and off by default).

For design work the usual entry point is creating a workspace (workspaces.create) with kind agent — it mints the bound Ajan token in the same step ("workspace first, token second").

What an Ajan token can never hold

The mint dialog will not produce, and the platform will not honour, an agent token with:

So an Ajan token structurally cannot approve its own work, set credentials, publish a design, or mint further tokens — not "is asked not to"; the scope registry refuses the grant.

First call: whoami

GET /v1/tokens/me

tokens.whoami answers with the store, kind (agent | developer), scopes, expiry and — for Ajan tokens — the bound workspace id. Call it before anything else: it tells you which store you are in (the token IS the store selector; there is no store argument anywhere) and which behaviour to expect from mutations (202-recorded vs executed). CLI: whoami.

Expiry and rotation posture

Generated from the live platform registries at build time — reference pages cannot go stale. Markdown variant: /agents-tokens.md