Architecture & Security Overview

Zentor App is built as a multi-tenant platform. Each tenant has a separate data context, and server-side checks restrict every authenticated request to the active tenant. The visible tenant switcher does not weaken that separation: it changes the active context for a user who has access to more than one tenant, while the backend still validates permissions for each request. Additional tenants are not created by ordinary users. They are enabled by Zentor, and the confirmed additional-tenant price for the Individual (Individuell) package is €39 per month.

Authentication for the dashboard is based on email and password, with optional TOTP two-factor authentication and supported SSO flows. A regular session JWT is valid for 12 hours, and a refresh token can remain valid for seven days. There is no separate developer API-key system for the documented public API. Public forms and content endpoints work without a dashboard login, while widget operations use a dedicated embed token together with origin restrictions. The embed token is shown in clear text only once and should be handled as a secret during deployment.

The platform combines the dashboard, tenant-scoped backend services, a knowledge base, communication channels and an isolated SIP deployment for telephony. The SIP voicebot has been separated from the main application since 24 July 2026. Each enabled tenant receives an isolated SIP instance, and activation or deactivation remains a Master Admin task. This separation prevents the tenant dashboard from directly managing trunks or low-level telephony infrastructure.

Security controls include IP, domain and country rules. Every new rule starts in dry-run mode and cannot be activated before a mandatory 24-hour waiting period. Allow rules take precedence over block rules. This design gives administrators time to inspect the effect of a rule before enforcement and reduces the risk of accidentally locking out legitimate access.

The architecture page should not be read as a public SLA or as a claim that every optional component is available in every package. Feature access depends on entitlements and add-ons. On-premises operation is prepared but not production-ready because the current licensing mechanism still contains a placeholder key. It should therefore be described as available on request and in introduction, not as a fully self-service deployment option.