Authentication · inmake docs

The access-token, identity-token and store headers; roles; where tokens come from.

Every request to the API carries a store and a credential. The credential is one of two headers, and what it may do is decided per request against the token's stored access tree — the same evaluation for the HTTP API, the SDK and the MCP server.

The three headers#

Header	Required	What it is
`access-token`	always	A store access token. Two families: private tokens (server-side, may write) and public tokens (safe in a browser, read-only groups).
`identity-token`	per user	A customer-scoped token minted from an access token (`secure/access`, op `identity`). Lets a browser act as one customer without ever holding a store token.
`store`	preferred	The store id. Can also travel in the request body as `store`, but the header is the canonical place.

Tokens are opaque strings; they never encode the store or role, and the raw value is never stored server-side — only an HMAC of it. A lost token is replaced, not recovered (unless CRM & Studio kept an encrypted copy at creation, see below).

Roles#

Each token carries a role that scopes what CRM & Studio lets it manage:

Role	Meaning
`master`	Cross-store super-admin. CRM & Studio's own credential; the only role that skips credit metering. Never mint one for an integration.
`owner`	Full control of one store, including minting other tokens.
`editor`	Read/write within the store's data, no token management.
`service`	Server and service accounts — the default for programmatic tokens and the right choice for a storefront backend or the MCP server.

Which routes a token may call is not the role but the access tree attached to it: a nested map of route groups (public, admin, process, …) to true/false with per-level fallbacks. A 403 means the path was denied by that tree; a 401 means no valid token was presented.

Where tokens come from#

CRM & Studio. Settings › Advanced › Tokens mints a token with a note, a role and an access tree, and keeps an encrypted copy so it can be revealed again later (the Reveal action, and the token picker in the Try-it rail on these pages). Needs the Develop capability on the store and a paid plan.
The API. POST /api/secure/access mints, lists, reveals and revokes tokens programmatically. Only master and owner tokens may mint; only master may mint another master. See Secure.
Identity tokens. secure/access with op: identity mints a customer-bound token fenced by an origin allowlist; it is revoked together with its parent.
Personal access tokens. A console member's own token (in_…, Profile › Personal access tokens) is not a store token: it is sent to the console host inmake.dev — its MCP endpoint, or /me/stores/{project}/token to exchange it for that member's store token — and acts with the member's role and capabilities. See Personal access tokens.

Errors#

Every error is JSON with the same shape:

{
  "error": "RequestError",
  "message": "Master role required",
  "body": { "…": "the sanitised request body" }
}

Status	Meaning
`400`	Bad request — a missing or invalid parameter (the message says which).
`401`	No valid `access-token` (or an identity token whose origin is not allowed).
`402`	Paid route and the store's wallet is empty — see Credits.
`403`	The token's access tree denies this path (or `Master role required`).
`404`	The document or store does not exist.
`409`	Conflict — for instance a store id that is already taken.
`500`	Internal error; the message is the exception text.