> ## Documentation Index > Fetch the complete documentation index at: https://docs.utmkit.co/llms.txt > Use this file to discover all available pages before exploring further. # Authentication & tokens > Mint a token on the console, choose what it may do, and send it as a bearer on every request. Every request to the API and every connection to the MCP server carries one header: ```text theme={null} Authorization: Bearer utmk_… ``` 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`. 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](/en/security/two-factor). 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. A token with an expiry stops working at the end of that day, UTC. Without one it works until you revoke it. 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. | Resource | Permission | What it allows | | ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Links | `links:read` | List and read links, and the workspace's tags | | Links | `links:write` | Create, edit and withdraw links; create tags | | Campaigns | `campaigns:read` | List and read campaigns | | Campaigns | `campaigns:write` | Create and rename campaigns | | Analytics | `analytics:read` | Read click and scan reports | | Rules | `rules:read` | Read the convention, approved values and dependency rules | | Rules | `rules:write` | Change the convention, approve and retire values, manage dependency rules | | Conversions | `conversions:write` | Report conversions from your own server. While the workspace holds a live token with this permission, every link's destination carries a reference your site can read back. See [Conversions](/en/analytics/conversions) | 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](/en/developers/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](/en/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.