Arquitetura e segurança em resumo

A Zentor App foi concebida como uma plataforma multi-tenant. Cada tenant tem o seu próprio contexto de dados, e verificações do lado do servidor restringem cada pedido autenticado ao tenant ativo. O seletor de tenant visível não enfraquece esta separação: apenas muda o contexto ativo para um utilizador com acesso a mais do que um tenant, enquanto o backend continua a validar as permissões em cada pedido. Tenants adicionais não são criados por utilizadores comuns. São ativados pela Zentor, e o preço confirmado para um tenant adicional no pacote Individual (Individuell) é de 39 €/mês.

A autenticação do dashboard baseia-se em e-mail e palavra-passe, com autenticação de dois fatores TOTP opcional e fluxos SSO suportados. Um JWT de sessão normal é válido durante 12 horas, e um token de atualização pode permanecer válido até sete dias. Não existe um sistema de chave de API para programadores separado para a API pública documentada. Os formulários públicos e os endpoints de conteúdo funcionam sem sessão iniciada no dashboard, enquanto as operações do widget utilizam um token de incorporação dedicado juntamente com restrições de origem. O token de incorporação é mostrado em texto simples apenas uma vez e deve ser tratado como um segredo durante a implementação.

A plataforma combina o dashboard, serviços de backend específicos por tenant, uma base de conhecimento, canais de comunicação e uma implementação SIP isolada para telefonia. O SIP-Voicebot está separado da aplicação principal desde 24 de julho de 2026. Cada tenant ativado recebe uma instância SIP isolada, e a ativação ou desativação continua a ser uma tarefa exclusiva do Master Admin. Esta separação impede que o dashboard do tenant faça a gestão direta de trunks ou de infraestrutura de telefonia de baixo nível.

Os controlos de segurança incluem regras de IP, domínio e país. Cada nova regra começa em modo de simulação (dry-run) e não pode ser ativada antes de um período de espera obrigatório de 24 horas. As regras de permissão têm prioridade sobre as regras de bloqueio. Este design dá aos administradores tempo para analisar o efeito de uma regra antes de esta ser aplicada e reduz o risco de bloquear acidentalmente um acesso legítimo.

A página de arquitetura não deve ser lida como um SLA público nem como a afirmação de que todos os componentes opcionais estão disponíveis em todos os pacotes. O acesso às funcionalidades depende de direitos (entitlements) e add-ons. A operação on-premises está preparada, mas não está pronta para produção, uma vez que o mecanismo de licenciamento atual ainda contém uma chave provisória. Deve, por isso, ser descrita como disponível mediante pedido e em fase de introdução, e não como uma opção de implementação totalmente self-service.