Verified against Semitexa Ultimate 2026.09.19.1020

Tenant Context Resolution

Semitexa decides the active tenant before configuration, data access, queues, and rendering continue downstream.

Tenant context propagationTenant context propagation. Request signal: Host, header, path, query. Resolver chain: First matching strategy wins. Tenant identity: Stable active tenant id. Execution context: Carries tenant downstream. Isolated layers: Config, data, jobs, UIinspectresolveactivatescopeRequest signalHost, header, path, queryResolver chainFirst matching strategywinsTenant identityStable active tenant idExecution contextCarries tenant downstreamIsolated layersConfig, data, jobs, UI
Tenant context propagation

How it works

The resolver chain tries the configured strategies in priority order. Each strategy inspects one transport signal -- subdomain, request header, path segment, or query parameter. The first match wins and becomes the tenant context for the rest of the execution.

The header strategy (X-Tenant-ID, or TENANCY_HEADER_NAME) is honoured only when the request comes from a trusted proxy: loopback, or a peer listed in TRUSTED_PROXIES, the same rule as X-Forwarded-Proto. Any client can send a header, so it is meant for a gateway in front of the app that authenticates the caller and sets the header itself. From any other peer the header is ignored and the next strategy in the chain decides.

Why this matters

If tenant resolution is ambiguous, every "isolated" layer above it becomes unreliable. That is why this boundary deserves explicit design -- the resolver chain makes the decision visible and deterministic instead of relying on implicit state.