Construyes en Lovable un panel de agenda para cinco clientes. Conectas tu Google Calendar, publicas la app y descubres que todos ven tu agenda. La interfaz puede parecer correcta, pero elegiste el tipo de conexión equivocado: una cuenta compartida para una función que debía usar la cuenta de cada persona.
Lovable distingue los conectores estándar, que reutilizan una sola cuenta, de los app user connectors, con los que cada usuario autoriza su propia cuenta. Su documentación oficial explica el flujo, las condiciones de acceso y una prueba importante: verifica con dos usuarios que una solicitud nunca lea datos del otro. Esta guía convierte esa documentación en una secuencia para un prototipo de calendario.
Decide primero de quién son los datos
Si tu app envía avisos desde un único Slack de la empresa, puede tener sentido un conector estándar. Si muestra la agenda, inbox o CRM personal de cada cliente, necesitas un conector por usuario. Lovable dice que, con el segundo, cada persona pasa por OAuth y el gateway aplica los permisos que esa persona concedió. Los tokens permanecen en el gateway y no se exponen en el código generado.
Escribe la función en una frase antes de conectar nada: «cada usuario ve solo sus próximos eventos de calendario y puede desconectar su cuenta». Esa frase fija el alcance. Para una vista de disponibilidad no pidas permiso para leer correos o archivos «por si acaso». Elige los scopes mínimos que soporten la función. Si después quieres crear eventos, revisa el permiso adicional y cómo lo explicas en la pantalla de consentimiento.
El recorrido de configuración
- Registra una app OAuth en el proveedor. Para Google, configura consentimiento y credenciales. Usa la URL de retorno que Lovable muestra en Connectors; su documentación indica
https://connector-gateway.lovable.dev/api/v1/app-users/oauth2/callback. Copia el valor actual de la interfaz y consérvalo idéntico en el proveedor; un cambio produceredirect_uri_mismatch. - Crea el cliente en Connectors. Añade client ID/secret, limita quién puede usarlo y enlázalo con el proyecto correcto. Que el constructor pueda usar su propia cuenta durante el desarrollo no equivale a que los usuarios de la app usen esa cuenta.
- Define la identidad del usuario. Una app pública necesita que cada visitante inicie sesión antes de conectar su Google Calendar. Lovable permite autenticación integrada o propia; en ciertas apps internas Business/Enterprise puede reutilizar la identidad del workspace. Revisa esa condición antes de pedir que se genere el botón.
- Pide la experiencia en el chat del proyecto. Usa el prompt siguiente y revisa el código y el flujo generado. No presupongas que un prompt prueba permisos por sí solo.
Crea en esta app un panel "Mi agenda". Cada usuario autenticado debe conectar
su propia cuenta de Google Calendar mediante el app user connector configurado.
Muestra solo sus próximos eventos, nunca los del creador del proyecto ni los
de otro usuario. Incluye estado desconectado, botón "Conectar Google Calendar",
mensaje claro si la sesión caduca y opción "Desconectar". No guardes títulos,
descripciones ni asistentes de eventos en la base de datos de la app. Solicita
solo los permisos necesarios para leer los eventos que se muestran. Antes de
publicar, enumera qué configuración de OAuth y qué pruebas con dos cuentas
debo completar manualmente.Es un prompt de implementación, no un experimento ejecutado por SoyJB en una cuenta de Lovable. Los nombres de menús y el comportamiento pueden variar según plan y proyecto; confirma el resultado en la documentación vigente y en tu app.
La prueba de dos cuentas antes de invitar clientes
Crea dos cuentas de prueba con eventos diferentes: A tiene «Reunión A» y B tiene «Reunión B». Conecta cada una por separado. En sesión A solo debe aparecer A; en sesión B solo B. Cierra sesión, vuelve a entrar y comprueba de nuevo. Desconecta A y verifica que la app deja de acceder a sus eventos. Si aparece el evento equivocado, detén el lanzamiento y revisa cómo el código identifica al usuario ante el gateway.
Comprueba también un error: revoca el permiso de Google de una cuenta y confirma que la app pide reconectar en vez de mostrar datos viejos como si fueran actuales. Lovable documenta un error de credencial caducada y un registro de actividad que ayuda a diagnosticar fallos de conexión. Haz la prueba con identidades de prueba, no con calendarios privados de clientes.
Dos límites que cambian el diseño
Acceso sin sesión. La documentación de Lovable indica que en Free y Pro el ajuste de Offline access queda habilitado para clientes creados allí; en Business y Enterprise está deshabilitado por defecto. Una app pública o con autenticación propia puede necesitarlo para usar el conector. Revísalo como una decisión de arquitectura: permite acciones fuera de la sesión, no equivale a un permiso nuevo en Google, y exige explicar y controlar qué puede hacer la app.
Copias de datos. El gateway respeta los permisos del origen al consultar Google, pero si copias eventos a la base de datos de Lovable esos permisos no se heredan automáticamente. El análisis técnico de Lovable recomienda no persistir datos sensibles cuando la app puede consultarlos en vivo; otra opción es guardar solo IDs y datos no sensibles. La conexión segura no sustituye tus reglas de acceso, borrado y retención.
Si vas a ofrecer la app a personas fuera de tu organización, revisa la guía oficial de verificación OAuth. Los scopes sensibles o restringidos pueden exigir revisión del proveedor; un grupo de usuarios de prueba no es lo mismo que una app pública aprobada. La ruta más rápida para validar la idea es probar con alcance mínimo y dos cuentas, sin prometer acceso masivo antes de completar la revisión.