Resumen de arquitectura y seguridad

Zentor App está diseñada como una plataforma multi-tenant. Cada tenant dispone de su propio contexto de datos, y las comprobaciones del lado del servidor restringen cada solicitud autenticada al tenant activo. El selector de tenant visible no debilita esta separación: solo cambia el contexto activo para un usuario con acceso a más de un tenant, mientras que el backend sigue validando los permisos en cada solicitud. Los tenants adicionales no los crean los usuarios habituales. Los activa Zentor, y el precio confirmado por un tenant adicional en el paquete Individual (Individuell) es de 39 € al mes.

La autenticación del panel se basa en correo electrónico y contraseña, con autenticación de dos factores TOTP opcional y flujos SSO compatibles. Un JWT de sesión habitual es válido durante 12 horas, y un token de actualización puede seguir siendo válido hasta siete días. No existe un sistema de clave API para desarrolladores independiente para la API pública documentada. Los formularios públicos y los endpoints de contenido funcionan sin iniciar sesión en el panel, mientras que las operaciones del widget utilizan un token de integración dedicado junto con restricciones de origen. El token de integración se muestra en texto claro solo una vez y debe tratarse como un secreto durante el despliegue.

La plataforma combina el panel, servicios de backend específicos de cada tenant, una base de conocimientos, canales de comunicación y un despliegue SIP aislado para la telefonía. El Zentor SIP-Voicebot está separado de la aplicación principal desde el 24 de julio de 2026. Cada tenant habilitado recibe una instancia SIP aislada, y la activación o desactivación sigue siendo tarea exclusiva del Master Admin. Esta separación evita que el panel del tenant gestione directamente troncales (trunks) o infraestructura de telefonía de bajo nivel.

Los controles de seguridad incluyen reglas por IP, dominio y país. Cada regla nueva se inicia en modo de prueba (dry-run) y no puede activarse antes de un periodo de espera obligatorio de 24 horas. Las reglas de permiso tienen prioridad sobre las de bloqueo. Este diseño da tiempo a los administradores para revisar el efecto de una regla antes de que se aplique y reduce el riesgo de bloquear accidentalmente un acceso legítimo.

La página de arquitectura no debe interpretarse como un SLA público ni como la afirmación de que cada componente opcional está disponible en todos los paquetes. El acceso a las funciones depende de los derechos (entitlements) y los add-ons. La operación on-premises está preparada, pero no lista para producción, ya que el mecanismo de licencias actual todavía contiene una clave provisional. Por ello, debe describirse como disponible bajo petición y en fase de introducción, no como una opción de despliegue totalmente autoservicio.