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

# Autenticación y tokens

> Emite un token en la consola, elige qué puede hacer, y envíalo como bearer en cada solicitud.

Cada solicitud a la API y cada conexión al servidor MCP lleva un encabezado:

```text theme={null}
Authorization: Bearer utmk_…
```

El token fija el espacio de trabajo. No hay ningún campo de espacio de trabajo,
organización ni usuario en ninguna parte de la API, ni tampoco ningún argumento de
herramienta para eso: un token emitido en el espacio de trabajo Acme actúa sobre Acme, y
nada que diga una solicitud puede moverlo.

## Emitir un token

Los tokens se emiten en la página **Tokens de API** de la consola, `https://app.utmkit.co/tokens`.

<Steps>
  <Step title="Revisa si tu espacio de trabajo exige autenticación en dos pasos">
    Si tu espacio de trabajo exige autenticación en dos pasos, emitir un token se rechaza
    hasta que la actives o inicies sesión mediante inicio de sesión único; la página lo
    indica. Ver [Autenticación en dos pasos](/es/security/two-factor).
  </Step>

  <Step title="Dale un nombre y elige sus permisos">
    Dale al token un nombre que diga dónde va a vivir ("Zapier", "trabajo de informes").
    Luego marca los permisos que necesita, y solo esos. El selector está agrupado por
    recurso, y solo ofrece lo que tu rol en el espacio de trabajo puede otorgar.
  </Step>

  <Step title="Opcionalmente pon una fecha de vencimiento">
    Un token con vencimiento deja de funcionar al final de ese día, UTC. Sin uno, funciona
    hasta que lo revoques.
  </Step>

  <Step title="Cópialo ahora">
    El token completo se muestra una vez, al emitirlo. Después la página solo muestra su
    prefijo, cuándo se creó y cuándo se usó por última vez. Si lo pierdes, revócalo y emite
    otro.
  </Step>
</Steps>

Cada miembro puede tener 10 tokens vigentes por espacio de trabajo, lo mismo en cada plan;
pasado eso, se rechaza el siguiente intento de emitir uno, no la siguiente solicitud.

## Los nueve permisos

Un permiso es una palabra que lleva el token. Cada operación de la API y cada herramienta
MCP declara el que necesita, y la referencia lo muestra en cada página.

| Recurso | Permiso | Qué permite |
| - | - | - |
| Enlaces | `links:read` | Listar y leer enlaces, las etiquetas del espacio de trabajo, códigos QR, destinos rotos y el plan y uso del espacio de trabajo |
| Enlaces | `links:write` | Crear, editar y retirar enlaces; crear, editar y eliminar etiquetas; etiquetar enlaces y moverlos entre campañas en lote |
| Campañas | `campaigns:read` | Listar y leer campañas |
| Campañas | `campaigns:write` | Crear y renombrar campañas |
| Analítica | `analytics:read` | Leer informes de clics y escaneos |
| Reglas | `rules:read` | Leer la convención, valores aprobados y reglas de dependencia |
| Reglas | `rules:write` | Cambiar la convención, aprobar y retirar valores, gestionar reglas de dependencia |
| Conversiones | `conversions:write` | Reportar conversiones desde tu propio servidor. Mientras el espacio de trabajo tenga un token vigente con este permiso, el destino de cada enlace lleva una referencia que tu sitio puede leer de vuelta. Ver [Conversiones](/es/analytics/conversions) |
| Informes | `reports:write` | Crear un enlace al informe en vivo del espacio de trabajo, para un cliente. Cualquiera que tenga el enlace puede leer el informe sin iniciar sesión, así que necesita un rol de administrador o propietario |

Las lecturas solo necesitan membresía. Las escrituras también necesitan que tu **rol** las
permita, y eso se verifica en vivo en cada llamada: un token emitido por un administrador
que luego se convierte en observador conserva sus permisos pero pierde las escrituras, en
la siguiente solicitud.

## Cómo se ve un rechazo

La API responde los rechazos en una sola forma, descrita en [Errores](/es/developers/errors). Los
que conciernen al token:

* **401 `unauthenticated`** — el token es desconocido, revocado, vencido, o quien lo tiene
  ya no es miembro. La puerta no dice cuál; las cuatro son el mismo hecho sobre la cuenta
  detrás de él.
* **402 `subscription_required` / `subscription_ended`** — la organización no tiene una
  suscripción vigente. Nada sobre el token arregla esto; ver [Facturación](/es/billing).
* **403 `missing_permission`** — el token no se emitió con el permiso que necesita esta
  operación. El mensaje lo nombra: `This token does not carry links:write.` Este es el
  único rechazo que puedes arreglar tú mismo, emitiendo un token con la casilla correcta
  marcada.
* **403 `role_forbids`** — el token lleva el permiso, pero tu rol en el espacio de trabajo
  no puede ejercerlo: `Your role in this workspace cannot do that.`

El servidor MCP habla las mismas frases, como resultados de herramienta que tu asistente
puede leer y transmitir. Una herramienta que al token le falta se oculta de su lista de
herramientas; llamada por nombre de todos modos, se rechaza con la frase de arriba en vez
de reportarse como desconocida.

## Revocar

Revoca un token en la página Tokens. La siguiente solicitud con él se rechaza con 401, y una
sesión MCP abierta muere con él: ninguna sesión sobrevive a su token.

## Mantenlo en secreto

Un token es una contraseña a un espacio de trabajo. Ponlo en una variable de entorno o un
gestor de secretos, nunca en un repositorio, una celda de hoja de cálculo o un mensaje de
chat. Si uno se filtra, revócalo primero y pregunta después.