Conectar con un clic

Autoriza Verifika desde tu asistente sin copiar ninguna llave. Cómo funciona, qué se concede y cómo se quita.

Hay dos formas de conectar un asistente a Verifika, y hacen exactamente lo mismo:

	Con un clic	Con una llave
Qué pegas	Nada, solo la URL	La URL y un secreto `vk_live_…`
Quién decide los permisos	Tú, en una pantalla de Verifika	Tú, al crear la llave en el panel
Dónde se quita	Integraciones → Aplicaciones	Integraciones → Llaves
Para qué sirve mejor	Tu asistente personal	Un servidor, un bot, un proceso sin persona detrás

Si tu cliente sabe hablar OAuth —Claude lo sabe— usa el de un clic. Es más seguro por una razón simple: nunca existe un secreto que puedas pegar en el sitio equivocado.

Cómo se ve

Añades el servidor en tu asistente con la URL https://api.verifika.tech/mcp y sin ninguna cabecera. En Claude: Ajustes → Conectores → Añadir conector personalizado.

El asistente descubre solo que el servidor pide autorización y abre tu navegador. Si no tenías sesión en Verifika, primero entras como siempre.

Verifika te pregunta. Ves quién pide, a qué dominio vuelve, en qué negocios y qué podrá hacer. Los permisos de lectura vienen marcados; los de escritura, no.

Aceptas y ya. El asistente recibe un permiso acotado a lo que marcaste. No hay ningún secreto que guardar.

Qué te va a preguntar la pantalla

En qué negocios. Solo salen aquellos donde tú administras integraciones. Si administras varios, se marcan a mano: una aplicación autorizada sobre un negocio no ve los demás, aunque adivine su identificador.

Qué podrá hacer. Los mismos permisos que una llave, con los mismos nombres. Lo que tu plan no incluye sale en gris con candado. Lo que escribe en el libro va marcado.

Mira el dominio, no el nombre

Cualquiera puede registrar una aplicación y ponerle el nombre que quiera —«Verifika Oficial» incluido—. Lo que no puede elegir libremente es el dominio al que vuelve, porque tiene que coincidir con el que registró. La pantalla te lo enseña siempre. Si no lo reconoces, no continúes.

Cuánto dura

	Cuánto	Qué pasa al vencer
El permiso de acceso	1 hora	Se renueva solo, sin preguntarte nada
Los permisos de escritura	15 minutos	Igual, pero la ventana es más corta a propósito
La renovación	30 días sin usarse	La conexión muere sola y hay que autorizar de nuevo
La autorización	No vence	Vive hasta que la quites

En la práctica: un asistente que usas a diario no vuelve a pedirte permiso nunca, y uno que abandonaste un mes se apaga solo sin que tengas que acordarte de él.

Cómo se quita

Integraciones → API pública y webhooks → Aplicaciones → Quitar acceso.

Corta en la siguiente petición, no cuando venza el permiso de acceso. Es la diferencia entre cerrar la puerta y esperar una hora a que se cierre sola: si quitas el acceso porque algo va mal, quieres que deje de entrar ya.

También caduca solo si la cuenta pierde el plan que incluye la API pública, o si quien la autorizó pierde el permiso de administrar integraciones.

Para quien construye el cliente

El servidor implementa el perfil de autorización de MCP sobre OAuth 2.1. Lo que necesitas:

Pieza	Dónde
Recurso protegido	`https://api.verifika.tech/mcp`
Metadatos del recurso (RFC 9728)	`https://api.verifika.tech/.well-known/oauth-protected-resource/mcp`
Servidor de autorización	`https://api.verifika.tech/api/auth`
Metadatos del servidor (RFC 8414)	`https://api.verifika.tech/.well-known/oauth-authorization-server/api/auth`

No hace falta que los memorices: un POST a /mcp sin token responde 401 con la cabecera WWW-Authenticate que apunta al primero, y desde ahí se descubre todo lo demás.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.verifika.tech/.well-known/oauth-protected-resource/mcp",
                         scope="incomes.read companies.read metrics.read …"

Lo que el servidor espera:

PKCE con S256. Obligatorio, también para clientes confidenciales.
resource=https://api.verifika.tech/mcp (RFC 8707) en la petición de autorización y en la de token. El token queda atado a ese recurso: fuera de él no vale.
Registro del cliente: Client ID Metadata Documents (lo recomendado hoy) o registro dinámico en POST /api/auth/oauth2/register, que sigue abierto porque varios clientes todavía lo usan.
offline_access si quieres poder renovar sin volver a pedirle permiso a la persona.

Las respuestas de autorización llevan iss (RFC 9207): compáralo con el emisor que descubriste antes de mandar el código al endpoint de token.

El scope que pides no es el que recibes

La persona puede conceder menos de lo que pediste — es el sentido de la pantalla. El scope de la respuesta del token dice qué se concedió de verdad, y tools/list te devolverá solo las herramientas que caben ahí. No asumas que tienes lo que pediste: mira lo que te dieron.

Preguntas que salen siempre

¿Necesito una llave además de esto? No. Son dos caminos al mismo sitio. Usa llave cuando no haya una persona que pueda autorizar —un servidor, un cron, un bot—.

¿La aplicación ve mi contraseña? No, y no puede: entras en Verifika, no en ella.

¿Puedo autorizar la misma aplicación otra vez con más permisos? Sí. Vuelve a conectarla y marca lo que falte; la pantalla llega con lo que ya habías concedido para que veas qué cambias. La autorización se reemplaza, no se acumula.

¿Y si alguien de mi equipo autoriza algo que no me gusta? Aparece en Integraciones → Aplicaciones con su nombre, la fecha y el último uso, y cualquiera que administre integraciones puede quitarlo.