Skip to main content
Every request to the API and every connection to the MCP server 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 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 eight 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.

​
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.