Esta página existe porque te pedimos algo sensible: acceso a tu cuenta publicitaria. Corresponde explicar exactamente qué hacemos con eso. Cinco preguntas, cinco respuestas.
¿Qué credenciales pedimos y con qué permisos?
Un solo token de lectura por plataforma. Nada más. No te pedimos el identificador de tu cuenta publicitaria: un token ya trae consigo a qué cuentas da acceso, así que las descubrimos en la misma llamada con la que lo validamos y te las mostramos para que elijas.
| Plataforma | Qué pedimos | Permiso mínimo |
|---|---|---|
| Meta Ads | Un access token | ads_read, con la cuenta asignada como "Ver rendimiento" |
| Google Ads | Nada que copiar: un botón te lleva a la pantalla de Google, elegís la cuenta y volvés | El permiso de la API de Google Ads, idealmente con un usuario de rol Solo lectura |
| TikTok Ads | Un access token. El identificador de anunciante es opcional, solo para una cuenta que no cuelgue de un Business Center | Lectura en Ads Management y Reporting |
Nunca pedimos usuario y contraseña, permisos de administración, acceso a facturación, ni credenciales de productos ajenos a la publicidad. Si un token viene con más permisos de los necesarios, el Servicio igual no puede usarlos: no tiene código para escribir.
¿Cómo se guardan?
- Se validan antes de guardarse, con una consulta de lectura real contra la plataforma. Si el token no funciona, no se guarda nada y el error se muestra en pantalla.
- No se guardan en nuestra base de datos. Van a un almacén de secretos gestionado, cifrado en reposo y aislado de la aplicación. Una copia de nuestra base no contiene ni un token.
- Un compartimento separado por usuario y plataforma, cuyo nombre se deriva de tu identidad ya autenticada y nunca de algo que venga en el pedido. No existe un camino desde un pedido a la credencial de otra persona.
- Nunca en archivos, variables de entorno ni repositorios de código.
- Nunca se escriben en los registros del sistema. Ninguna línea de registro incluye el valor de una credencial: cuando una llamada a una plataforma falla se registra el tipo de error, nunca el pedido ni la respuesta.
- Nunca se muestran ni se devuelven. En tu panel ves los últimos 4 caracteres y el nombre de la cuenta. No hay ningún endpoint que devuelva el valor: ni para vos, ni para nosotros desde la aplicación.
¿Quién puede acceder?
- La aplicación, únicamente durante una consulta que vos iniciaste. Se lee en memoria, se usa y se descarta al terminar. No queda en caché entre sesiones, y su permiso está acotado por configuración a los compartimentos de credenciales: no alcanza ningún otro secreto de la empresa.
- No hay ninguna pantalla, endpoint ni exportación que le muestre una credencial a una persona, ni siquiera a un administrador del Servicio.
- Dicho con precisión, porque es la pregunta que importa: un grupo reducido de administradores de nuestra infraestructura en la nube tiene, por su rol, la capacidad técnica de leer el almacén de secretos, igual que la tiene sobre cualquier otro sistema de la empresa. No es un acceso que la aplicación ofrezca ni que se use para operarla; es lo que implica administrar la infraestructura donde corre. Está limitado a ese grupo y sujeto a las políticas internas de Winclap.
- La creación y la destrucción de cada compartimento quedan registradas en el almacén, con la fecha y la identidad que las ejecutó.
¿Cuándo y cómo se eliminan?
| Momento | Qué pasa |
|---|---|
| Cuando termina tu ventana de demostración — 48 h de acceso desde la aprobación | Destrucción automática y definitiva. Un proceso corre cada 30 minutos y se lleva todo lo vencido. Recibís un email de confirmación |
| 6 h antes del cierre de tu ventana | Email de aviso de vencimiento |
| Mientras tu acceso está pausado | El reloj se congela y tus credenciales sobreviven: la pausa es un freno nuestro y no te consume el tiempo. Podés desconectarlas igual |
| Cuando vos quieras | Botón "Desconectar" en el panel: destrucción inmediata, en cualquier estado de tu cuenta |
| Cuando revoques del lado de la plataforma | El token deja de funcionar al instante, incluso antes de que lo destruyamos |
Se destruye el compartimento entero, no una versión: no queda un valor anterior recuperable. Las copias de respaldo de la base no contienen credenciales, porque la base nunca las tuvo — el detalle, en el punto 8 de la Política de Privacidad.
Destruir no es revocar, y conviene que lo sepas. Cuando destruimos tu credencial dejamos de tener acceso a tu cuenta, pero el token en sí sigue siendo válido del lado de la plataforma que lo emitió hasta que vos lo revoques ahí. Nosotros no lo revocamos por vos: hacerlo implicaría usar tu credencial para una operación que no pediste. Cómo revocarla, abajo.
¿Qué pasa con los datos de mis campañas?
No se almacenan. El recorrido es: tu asistente le pide algo a nuestro servidor, nuestro servidor se lo pide a la plataforma con tu token, y la respuesta vuelve por el mismo camino hasta tu asistente.
Los datos pasan en memoria y salen. No queda registro del contenido de ninguna consulta: ni una métrica, ni un nombre de campaña, ni un monto. No existe una tabla donde escribirlos. Lo único que queda es lo que registra cualquier servidor web —fecha, ruta pedida, código de respuesta— durante 30 días.
Cómo revocar, de tu lado
La garantía que no depende de nosotros:
- Meta: Configuración del negocio → Usuarios del sistema → generar un token nuevo o eliminar el usuario.
- Google: myaccount.google.com/permissions, o quitar el usuario en Google Ads → Acceso y seguridad.
- TikTok: Business Center → Autorizaciones → revocar la aplicación.
Reportar un problema de seguridad
Si encontrás una vulnerabilidad, escribinos a legal@winclap.com. Respondemos en 48 horas hábiles y no iniciamos acciones legales contra quien reporte de buena fe y sin acceder a datos de terceros.