Skip to main content
Every request to the API, and every connection to the MCP server made with a token, carries one header:
The token fixes the workspace. There is no workspace, organization or user field anywhere in the API, and no tool argument for one either: a token minted in the Acme workspace acts on Acme, and nothing a request says can move it.

​
Minting a token

Tokens are minted on the console’s API tokens page, https://app.utmkit.co/tokens.
1

Check whether your workspace requires two-factor authentication

If your workspace requires two-factor authentication, minting is refused until you turn it on or sign in through single sign-on; the page says so. See Two-factor authentication.
2

Name it and choose its permissions

Give the token a name that says where it will live (“Zapier”, “reporting job”). Then tick the permissions it needs, and only those. The picker is grouped by resource, and it only offers what your role in the workspace can grant.
3

Optionally set an expiry date

A token with an expiry stops working at the end of that day, UTC. Without one it works until you revoke it.
4

Copy it now

The full token is shown once, at minting. Afterwards the page shows only its prefix, when it was created and when it was last used. If you lose it, revoke it and mint another.
Each member may hold 10 live tokens per workspace, the same on every plan; past that, the next mint is refused, not the next request.

​
The nine permissions

A permission is a word the token carries. Each API operation and each MCP tool declares the one it requires, and the reference shows it on every page. Reads need only membership. Writes also need your role to allow them, and that is checked live on every call: a token minted by an admin who is later made a viewer keeps its permissions but loses the writes, on the very next request.

​
What a refusal looks like

The API answers refusals in one shape, described in Errors. The ones that concern the token:
  • 401 unauthenticated — the token is unknown, revoked, expired, or its holder is no longer a member. The door does not say which; all four are the same fact about the account behind it.
  • 402 subscription_required / subscription_ended — the organization has no live subscription. Nothing about the token fixes this; see Billing.
  • 403 missing_permission — the token was not minted with the permission this operation needs. The message names it: This token does not carry links:write. This is the one refusal you can fix yourself, by minting a token with the right box ticked.
  • 403 role_forbids — the token carries the permission, but your role in the workspace cannot exercise it: Your role in this workspace cannot do that.
The MCP server speaks the same sentences, as tool results your assistant can read and relay. A tool the token lacks is hidden from its tool list; called by name anyway, it is refused with the sentence above rather than reported as unknown.

​
Revoking

Revoke a token on the Tokens page. The next request with it is refused with 401, and an open MCP session dies with it: no session outlives its token.

​
Connected applications

An assistant that connects to the MCP server by signing in — claude.ai, Claude Desktop’s connectors, the Claude mobile app, Claude Code — does not need a token from this page. It sends you to a UTMKit consent page, where you choose the workspace and tick the permissions from the same list above; nobody can grant more than their role allows. What it receives is listed on the Tokens page under Connected applications, with the person who connected it, its permissions and when it was last used.
  • Lifetime. It stays connected while it is used at least once every 30 days. Its access renews itself every hour without asking you again.
  • Disconnecting. You can disconnect your own; an owner or admin can disconnect anyone’s. The next request is refused, and the activity log records who did it. If a renewal is ever replayed — a sign that a copy exists — UTMKit cuts the connection itself and logs that too.
  • Only for the MCP server. A connection’s credentials start with utmo_ and utmr_ and open https://app.utmkit.co/mcp only; the REST API refuses them. Scripts and integrations keep using utmk_ tokens.
For client authors: the server follows the MCP authorization specification. A request without credentials gets 401 with WWW-Authenticate: Bearer resource_metadata="https://app.utmkit.co/.well-known/oauth-protected-resource/mcp"; the authorization server’s metadata is at https://app.utmkit.co/.well-known/oauth-authorization-server. It supports the authorization code grant with PKCE (S256) for public clients, the resource parameter, refresh-token rotation, dynamic client registration and client ID metadata documents.

​
Keep it secret

A token is a password to one workspace. Put it in an environment variable or a secrets manager, never in a repository, a spreadsheet cell or a chat message. If one leaks, revoke it first and ask questions after.