Autenticación (claves de API y OAuth)
La API REST y el servidor MCP aceptan dos tipos de credencial bearer: una clave de API que creas en los ajustes o un token de acceso OAuth 2.1 que una aplicación recibe después de que la apruebes. Ambas se resuelven a una cuenta, llevan un conjunto de permisos y se vuelven a comprobar contra los permisos de equipo en cada petición.
Claves de API
Crea una clave en los ajustes, elige los permisos que puede usar y, si quieres, dale una fecha de caducidad. El secreto se muestra una sola vez al crearlo y solo se guardan sus últimos caracteres, así que una clave perdida se reemplaza, no se recupera. Envíala como cabecera Authorization bearer. Las claves llevan un prefijo reconocible y una suma de verificación, lo que permite a los escáneres de secretos atribuir una clave filtrada y al servidor rechazar una malformada sin consultar la base de datos.
Claves de equipo
Una clave puede pertenecer a un equipo en lugar de a ti personalmente, creada desde los ajustes del equipo por un miembro con permiso para gestionar claves de API. Una clave de equipo queda limitada a ese único equipo: puede leer y modificar ese equipo, sus miembros, sus invitaciones y su facturación, y cualquier otro equipo se rechaza con un 403. Tampoco puede acceder a operaciones de la cuenta — el perfil, las sesiones, crear un equipo o gestionar claves de API — que requieren una clave personal. Una clave tampoco concede más de lo que ya tiene su propietario: los permisos de equipo se evalúan en cada petición, así que la clave pierde el acceso en cuanto lo pierde su propietario.
OAuth para aplicaciones y agentes
Las aplicaciones de terceros y los clientes de agentes usan el flujo de código de autorización de OAuth 2.1 con PKCE. El cliente descubre los endpoints, te envía a una pantalla de consentimiento que enumera exactamente lo que pide y recibe un token de acceso y un token de refresco cuando lo apruebas. Las integraciones de confianza deben usar un documento estable de metadatos del ID de cliente o un ID emitido por un operador. El registro dinámico abierto sigue disponible como alternativa de compatibilidad; cada ID generado se revisa por separado y empieza sin verificar.
Permisos
Los permisos son concesiones amplias a nivel de recurso. Solo reducen lo que su propietario ya puede hacer — nunca añaden permisos — y un único catálogo alimenta las claves de API, la pantalla de consentimiento y los esquemas de seguridad de OpenAPI.
| profile:read | Leer el perfil, las sesiones y las preferencias de tu cuenta. |
| profile:write | Actualizar el perfil de tu cuenta y revocar tus sesiones. |
| teams:read | Listar los equipos a los que perteneces y leer sus detalles. |
| teams:write | Crear equipos y cambiar los detalles de los equipos. |
| members:read | Listar los miembros de tus equipos. |
| members:write | Cambiar y eliminar miembros de tus equipos. |
| invites:write | Enviar y revocar invitaciones a tus equipos. |
| billing:read | Leer el estado de suscripción y facturación de tus equipos. |
| api-keys:read | Ver las claves de API de tu cuenta y cuándo se usaron por última vez. |
| api-keys:write | Crear y revocar claves de API en tu cuenta. |
Revocar el acceso
Revoca una clave, o el acceso de una aplicación, en Ajustes → API y MCP; revocar una concesión también destruye los tokens emitidos con ella. Las credenciales se cachean brevemente para que las peticiones sigan siendo rápidas, así que una revocación se aplica de inmediato donde se realiza y llega al resto de la red aproximadamente un minuto después.
Límites de velocidad y errores
Las peticiones REST autenticadas y las llamadas a herramientas MCP comparten un límite de 300 peticiones por cada 60 segundos y credencial. Los intentos de autenticación fallidos se limitan por separado por dirección IP; superar cualquiera de los límites devuelve un 429 con la cabecera retry-after. Cada respuesta REST indica el contador que consumió en RateLimit-Limit, RateLimit-Remaining y RateLimit-Reset, para que un cliente pueda ajustar su ritmo antes de que se le rechace. Cada fallo es un documento de problema RFC 9457 cuyo miembro code es un identificador estable en lugar de texto traducido, de modo que los scripts y los modelos pueden reaccionar a él.