Cómo está construido Universal Inbox

Arquitectura y stack tecnológico

1. Vista general

Universal Inbox es una aplicación web (Next.js, App Router) con TypeScript en todo el código — tanto en la interfaz como en la lógica de servidor. No hay una app nativa separada: el mismo código atiende escritorio y celular mediante diseño responsivo.

2. Hosting y despliegue

La aplicación se aloja en Vercel, sobre funciones serverless con escalamiento automático — no hay un servidor fijo que administrar ni parchear manualmente. Todo el tráfico se sirve por HTTPS; Vercel fuerza TLS en todas las rutas.

Los despliegues salen directamente de un repositorio de control de versiones (Git) privado. Cada cambio pasa por una batería de verificación automatizada antes de poder desplegarse: análisis estático de código (lint), verificación de tipos de TypeScript, pruebas unitarias, y una compilación de producción completa. Cualquier etapa que falle detiene el despliegue — no llega a producción.

Además, un segundo proceso independiente levanta una instancia limpia de la base de datos desde cero, le aplica todo el historial de migraciones versionadas y corre pruebas de integración contra ella. Esto verifica en cada cambio que el esquema, las políticas de seguridad y las funciones de base de datos siguen funcionando como se espera, sin tocar datos de producción.

Los cambios de esquema de base de datos viven como migraciones versionadas dentro del mismo repositorio, no como modificaciones manuales aplicadas a mano sobre la base de producción — el estado de la base es reproducible y auditable.

3. Base de datos

Supabase (Postgres administrado) es la única base de datos operativa de la aplicación. Es un proveedor especializado en Postgres, no una base de datos casera — hereda las prácticas de disponibilidad, respaldo y cifrado en reposo propias de ese proveedor.

La separación entre organizaciones (multi-tenancy) se refuerza mediante Row Level Security (RLS) de Postgres — no solo mediante filtros en el código de la aplicación. Esto se detalla en la sección de Seguridad.

4. Tareas programadas

Los procesos en segundo plano (por ejemplo, sondeo de buzones de correo, envío en lotes de campañas masivas, respuestas del Agente de IA) corren mediante pg_cron (extensión nativa de Postgres) disparando rutas HTTP protegidas — nunca corren directamente contra datos de producción sin pasar por la misma capa de autenticación y RLS que el resto de la aplicación.

Las rutas que requieren conexiones de red de bajo nivel (por ejemplo, IMAP para leer buzones de correo) se declaran explícitamente con runtime Node.js en vez del runtime “Edge” — una decisión técnica deliberada, ya que Edge no soporta sockets TCP crudos.

Seguridad y control de acceso

1. Aislamiento entre organizaciones, a nivel de base de datos

El aislamiento entre clientes no depende únicamente del código de la aplicación. Cada tabla relevante lleva una columna organization_id, y las políticas de Row Level Security de Postgres son las que deciden, dentro de la propia base de datos, qué fila puede leer o modificar cada usuario. Un error de lógica en una consulta de la aplicación no puede, por sí solo, filtrar datos entre organizaciones — la base de datos rechazaría el acceso de todas formas.

Esto es una segunda capa de defensa, independiente de que el código de la aplicación también filtre correctamente por organización.

2. Autenticación y roles

La autenticación de usuarios corre sobre Supabase Auth — las contraseñas de los usuarios nunca se almacenan ni se manejan como texto plano dentro del código de la aplicación; las gestiona el proveedor de autenticación.

Existen tres niveles de acceso: Agente (acceso a las conversaciones de su organización), Administrador de organización (además, configuración de su propia organización) y Platform Admin (personal de Manifesto Marketing Group con acceso administrativo global, necesario para dar de alta organizaciones, vincular activos y dar soporte). El nivel de acceso se valida tanto en el código de la aplicación como dentro de las propias políticas de RLS de la base de datos.

Las acciones especialmente sensibles exigen una reautenticación por contraseña en el momento de ejecutarlas, aunque la sesión del usuario ya esté abierta y vigente. La exportación completa de la información de una organización es el primer caso donde se aplica: contempla el escenario de una sesión de administrador dejada abierta y sin supervisión, donde un diálogo de confirmación simple no aportaría ninguna garantía real.

3. Credenciales de integraciones (API keys, tokens, contraseñas)

Las credenciales de integración se almacenan cifradas en un gestor de secretos dedicado (Supabase Vault), no como texto legible dentro de una tabla de la aplicación. La tabla de configuración de cada organización guarda únicamente una referencia al secreto; el valor real se descifra bajo demanda, del lado del servidor, mediante una función de base de datos con permisos restringidos.

Esto aplica a los tokens de System User de Meta, el token de conexión CRM del dataset, la API key de OpenAI del Agente de IA y la credencial del proveedor de envío de correo. Estas credenciales:

• Nunca se envían al navegador — solo se descifran del lado del servidor, en el momento exacto en que se necesitan (por ejemplo, al mandar un correo).
• No se vuelven a mostrar en la interfaz una vez guardadas — la pantalla de configuración solo indica que existe una credencial y su fecha de actualización, con opción de reemplazarla. Revelar el valor real está reservado exclusivamente al rol de Platform Admin y es una acción deliberada, nunca el estado por defecto de la pantalla.
• Viven fuera del código fuente — nunca se escriben directamente en el repositorio.

La única credencial que deliberadamente no se cifra de esta forma es la API key de ingesta de formularios web: por diseño es un identificador público, ya que viaja dentro del código del formulario embebido en el sitio web de la propia organización. Su tratamiento se detalla más abajo.

4. Verificación de autenticidad de webhooks entrantes

Los mensajes entrantes de Meta (WhatsApp, Messenger, Instagram) llegan mediante webhooks. Cada solicitud se valida con una firma criptográfica HMAC-SHA256 (header X-Hub-Signature-256), calculada con el secreto de la aplicación y comparada con el valor recibido usando comparación de tiempo constante (timing-safe) — cualquier solicitud sin firma válida se rechaza con estatus 401 antes de procesar un solo dato. Esto evita que un tercero pueda inyectar mensajes falsos simulando ser Meta.

Las plataformas de mensajería pueden reentregar un mismo evento más de una vez (por reintentos o por su propia mecánica de entrega). Los mensajes entrantes se deduplican por su identificador único de mensaje antes de insertarse, de modo que una reentrega no genera un mensaje duplicado en la conversación ni dispara dos veces las automatizaciones asociadas.

5. Firma de webhooks salientes

Universal Inbox también puede emitir webhooks hacia sistemas externos de la organización (n8n, Zapier, un CRM propio) cuando un Workflow así lo define. Ese envío se firma con HMAC-SHA256 usando un secreto propio de cada organización, transmitido en el header X-Universal-Inbox-Signature.

De esta forma, el sistema receptor puede verificar criptográficamente que la solicitud proviene realmente de Universal Inbox y que el contenido no fue alterado en tránsito, en lugar de confiar únicamente en que la URL del webhook permanezca secreta. El secreto de firma es regenerable por la organización en cualquier momento.

6. Endpoints de tareas programadas

Las rutas que disparan procesos en segundo plano (sondeo de correo, envío de campañas, etc.) están protegidas con un secreto compartido, enviado como token Bearer en el header de autorización — no son endpoints públicos invocables sin ese secreto.

7. Archivos adjuntos

Las imágenes, documentos y notas de voz que se comparten en una conversación se almacenan en un bucket privado y se sirven mediante URLs firmadas de vida corta — no existen URLs públicas permanentes para los archivos adjuntos de una conversación.

8. Contenido HTML de correo entrante

El contenido HTML de un correo entrante proviene de un remitente externo, no confiable por definición. Se sanitiza del lado del servidor antes de guardarse o mostrarse (se elimina cualquier script o markup peligroso), tratando este caso con el mismo cuidado que cualquier entrada de usuario no confiable — es el único canal de los que soporta Universal Inbox que entrega markup en vez de solo texto plano.

9. Endpoint público de ingesta de formularios web

Cuando una organización publica un formulario web construido en Universal Inbox, el snippet que se instala en su sitio envía las respuestas a un endpoint de ingesta. Ese endpoint es público por necesidad — cualquier visitante del sitio debe poder llenar el formulario sin autenticarse — y por eso se trata con medidas específicas:

• Cada organización tiene su propia API key de ingesta, generada por la plataforma. Identifica a qué organización pertenece cada envío recibido; un envío sin una key válida se rechaza.
• La key es regenerable en cualquier momento: al regenerarla, la anterior deja de funcionar de inmediato, lo que permite cortar el acceso si el snippet quedó expuesto donde no debía.
• El formulario incluye un campo trampa (honeypot) invisible para una persona pero visible para un robot de spam: cualquier envío que lo llene se descarta antes de crear registro alguno.
• Esta key nunca da acceso de lectura a la información de la organización — únicamente permite depositar una respuesta de formulario.

Datos, almacenamiento y retención

1. Cifrado en tránsito y en reposo

Todo el tráfico entre el navegador, la aplicación y la base de datos viaja cifrado (HTTPS/TLS). Los datos en reposo están cifrados a nivel de la infraestructura del proveedor de base de datos administrada (Supabase), conforme a las prácticas estándar de ese proveedor.

2. Qué información se almacena

3. Registro de actividad y trazabilidad

Cada mensaje saliente guarda quién lo mandó (una persona del equipo o una automatización específica — Agente de IA, Workflow, campaña masiva), con marca de tiempo. El historial de una conversación no se edita retroactivamente.

Más allá de los mensajes, la plataforma mantiene bitácoras dedicadas de los eventos que modifican el estado del negocio:

• Cambios de estatus de conversaciones y formularios: estatus anterior, estatus nuevo, quién lo cambió y cuándo — poblado automáticamente a nivel de base de datos, sin importar si el cambio vino de una persona, de un Workflow o del Agente de IA.
• Cambios a datos de contacto: valor anterior, valor nuevo y origen del cambio (edición manual, relleno automático desde un formulario, fusión de duplicados o Agente de IA).
• Ejecuciones de Workflows: qué regla se disparó, con qué resultado (éxito o error, con el mensaje de error correspondiente) y sobre qué registro.
• Eventos de conversión enviados a Meta: qué evento, qué persona lo confirmó y cuándo, junto con la respuesta de la plataforma.
• Recordatorios y notas internas: creación, aplazamiento, cumplimiento, reapertura o eliminación, con autor y marca de tiempo.

Estas bitácoras son consultables desde la propia aplicación mediante reportes de auditoría, sin requerir acceso directo a la base de datos ni intervención de soporte técnico.

4. Retención y eliminación

La retención y eliminación de datos se rige por lo descrito en el Aviso de Privacidad de la aplicación: los datos se conservan durante la relación contractual y el tiempo razonablemente necesario para operar el servicio, y pueden eliminarse o exportarse al término de la relación conforme a lo acordado con cada organización.

5. Portabilidad — exportación de datos por autoservicio

Un Administrador de organización puede exportar la información de su propia organización directamente desde la aplicación, sin depender de una solicitud a soporte técnico ni de un proceso manual de Manifesto Marketing Group.

La exportación se solicita por categorías de negocio (contactos, conversaciones y mensajes, formularios y leads, catálogo y base de conocimiento, workflows, envíos masivos, recordatorios) y se procesa en segundo plano, generando un archivo ZIP con un CSV por tabla más un archivo descriptivo del contenido. El formato es abierto y legible por cualquier hoja de cálculo o sistema destino, sin dependencia de la plataforma.

El manejo del archivo generado sigue el mismo criterio de mínima exposición que el resto de la plataforma:

• Se almacena en un bucket privado, nunca en una ubicación de acceso público.
• Cada descarga se sirve mediante una URL firmada de vida corta, generada en el momento del clic.
• El archivo se elimina automáticamente a los 7 días; el registro de que la exportación fue solicitada, por quién y cuándo, se conserva de forma permanente como parte de la bitácora.
• Nunca incluye credenciales — ninguna API key, token ni contraseña de integración viaja en una exportación, bajo ninguna circunstancia.
• Solicitarla exige reautenticación por contraseña (ver Seguridad).

Integraciones con terceros

1. Meta (WhatsApp, Messenger, Instagram)

La integración corre exclusivamente sobre las APIs oficiales de Meta (Graph API, WhatsApp Business Platform) — no se usan librerías no oficiales ni automatización que simule un cliente de WhatsApp normal. Los mensajes entrantes llegan por webhook firmado (ver Seguridad); los salientes se mandan directamente contra la API oficial.

2. Meta Conversions API

El envío de un evento de conversión es una acción manual y explícita de una persona del equipo, nunca automática. Los datos de contacto aplicables (teléfono, correo, nombre) se transforman mediante funciones criptográficas de hash antes de transmitirse, cuando la API correspondiente lo requiere.

3. Email — envío

El envío de correo se realiza mediante un proveedor de envío transaccional (por ejemplo, Resend) o mediante el servidor SMTP propio que la organización decida configurar. El dominio de envío pertenece siempre a la organización cliente, con sus propios registros de autenticación (SPF/DKIM) — la reputación de entrega de ese dominio es responsabilidad y control de la organización, no de la infraestructura compartida de Manifesto Marketing Group.

Todo correo enviado como parte de un envío masivo incluye un enlace de baja que apunta a una ruta pública de la aplicación. El destinatario puede darse de baja sin necesidad de cuenta ni de intervención del equipo, y esa decisión se refleja de inmediato en su registro de contacto, excluyéndolo de campañas posteriores.

4. Email — recepción

Cuando una organización quiere que las respuestas de correo lleguen a la bandeja de Universal Inbox, autoriza el acceso a su buzón real mediante IMAP sobre conexión cifrada. La detección de mensajes nuevos se hace por identificador único de mensaje (UID), no por fecha ni por marcas de “leído” — evita reprocesar correos y es resistente a que alguien revise la bandeja normal de correo en paralelo.

Cada buzón conectado se procesa de forma aislada: si un buzón falla (credencial vencida, servidor caído), no afecta el procesamiento de los demás buzones ni del resto de la aplicación.

5. Agente de Inteligencia Artificial (OpenAI)

Cuando una organización activa el Agente de IA, el contenido relevante de la conversación se envía a la API de OpenAI para generar la respuesta automatizada. Cada organización usa su propia API key de OpenAI, configurada y almacenada bajo el mismo tratamiento que el resto de las credenciales de integración (ver Seguridad) — el consumo lo cubre la organización directamente con su proveedor, no una cuenta compartida.

La base de conocimiento no se transmite completa en cada consulta. El contenido se indexa previamente mediante embeddings (representaciones numéricas del significado del texto) y, ante cada pregunta, una búsqueda semántica ejecutada dentro de la propia base de datos selecciona únicamente los fragmentos más relevantes; solo esos fragmentos acompañan a la consulta. El resultado es que se transmite la menor cantidad de información posible para responder, en vez de exponer todo el acervo de la organización en cada intercambio.

El mismo criterio y la misma API key aplican al Asistente de ayuda de la aplicación, que responde dudas del equipo sobre cómo usar Universal Inbox y opera sobre documentación de producto, no sobre datos de contactos ni conversaciones.

Esta función es opcional: una organización que no active estas herramientas no envía ningún dato a OpenAI.

6. Alcance de las integraciones

En todos los casos, cada integración se limita a los datos estrictamente necesarios para operar el canal solicitado por la organización, y ningún dato se vende ni se comparte con terceros fuera de ese propósito.

Disponibilidad y continuidad

1. Infraestructura

El hosting serverless (Vercel) escala automáticamente según demanda, sin un servidor único que represente un punto de falla. La base de datos administrada (Supabase) opera bajo las prácticas de disponibilidad y respaldo propias de ese proveedor.

2. Dependencias externas

La disponibilidad de ciertos canales depende de plataformas externas fuera del control directo de Manifesto Marketing Group: las APIs de Meta, el proveedor de envío de correo y el proveedor del buzón de correo conectado por la organización. Una interrupción, cambio de política o bloqueo originado en esas plataformas puede afectar temporalmente el canal correspondiente, sin que sea un problema de la infraestructura propia de Universal Inbox.

3. Gestión de dependencias de código abierto

El código de la aplicación utiliza librerías de código abierto de terceros, como cualquier aplicación web moderna. Se auditan regularmente en busca de vulnerabilidades conocidas; cuando una vulnerabilidad real aplica a una librería usada en producción y existe una versión corregida, se actualiza. Cuando el registro público (npm) no tiene disponible la versión corregida de una librería pero el mantenedor sí la publica por otro canal oficial, se instala esa versión corregida en su lugar en vez de quedarse con la vulnerable.

4. Control de una organización sobre sus propios canales

Cada organización puede pausar o revocar el acceso a un canal conectado (un buzón de correo, un número de WhatsApp, una cuenta de Instagram) en cualquier momento, sin que eso afecte a los demás canales de la misma organización ni a otras organizaciones.

5. Visibilidad del consumo

Cada organización puede consultar su propio consumo directamente en la aplicación: almacenamiento utilizado (archivos adjuntos, documentos y medios de conversación) y contactos activos del mes en curso. La medición se calcula sobre los datos reales de esa organización y sirve para planeación de capacidad y previsibilidad, sin depender de un reporte solicitado a soporte.

6. Contacto técnico

Para solicitar un cuestionario de seguridad específico de tu organización, una llamada técnica, o aclarar cualquier punto de este documento, contacta a Manifesto Marketing Group.