Skip to main content
Documentation
StartOverviewArchitectureAuthenticationSend your first message
TypeScript SDKOverviewTrusted app serverApp-user clientsRealtimeErrors & webhooks
Flutter SDKOverviewInstallationAuthenticationChannels & messagesOffline & syncRealtimeUI componentsPush & lifecycle
ConceptsTenancy & scopeChannels & messagesDelivery & reconciliationSecurity checklist
ProtocolsRealtimeSigned webhooks
ReferenceREST APIErrors, limits & retriesDeploy docs to Coolify
VV ChatDocs API v1
Recommended starting points
Build chat without rebuilding infrastructureV Chat is a multi-tenant messaging backend with typed server, web, and Flutter integration paths.StartArchitecture at a glanceUnderstand the control plane, data plane, realtime path, and SDK boundaries before integrating.StartAuthentication and credentialsSelect the correct credential for dashboard, trusted-server, app-user, realtime, and webhook flows.StartSend your first messageUse the trusted TypeScript server client to create the minimum safe messaging flow.StartTypeScript SDK overviewChoose the correct typed client for trusted servers, app users, dashboard sessions, realtime, and webhooks.TypeScript SDKTrusted app-server clientUse AppServerClient from a protected backend to manage data-plane resources and mint app-user tokens.TypeScript SDKApp-user clientsBuild browser or Node app-user flows with VChatClient or the lower-level AppUserClient.TypeScript SDK
↑↓ Navigate↵ Openesc Close
API reference
StartOverviewArchitectureAuthenticationSend your first message
TypeScript SDKOverviewTrusted app serverApp-user clientsRealtimeErrors & webhooks
Flutter SDKOverviewInstallationAuthenticationChannels & messagesOffline & syncRealtimeUI componentsPush & lifecycle
ConceptsTenancy & scopeChannels & messagesDelivery & reconciliationSecurity checklist
ProtocolsRealtimeSigned webhooks
ReferenceREST APIErrors, limits & retriesDeploy docs to Coolify
Contract sourceOpenAPI JSON
Docs/Concepts
Isolation model

Tenancy and environment scope

Understand how organization, tenant, application, environment, and app-user scope prevent cross-customer access.

Updated 2026-08-09•AGENTS.md tenant invariants · docs/architecture/TENANCY_MODEL.md

Scope hierarchy

  1. A dashboard identity belongs to one or more organizations through explicit memberships.
  2. An organization owns applications. Runtime data is scoped to a verified tenant and application.
  3. Each application separates environments such as development, staging, and production.
  4. App users, channels, messages, jobs, events, webhooks, and support actions remain inside that exact scope.

Where scope comes from

Scope comes from verified dashboard membership, application credentials, or app-user token claims. A client-provided tenantId, appId, environment, userId, or resource path is never enough by itself to authorize access.

Neutral foreign-resource behavior

Missing, foreign, wrong-environment, inactive, and policy-denied resources normally return the same resource-not-found outcome so callers cannot probe another scope.

Client-side rule

A cache key, selected application, route parameter, or visible UI row is not authorization proof. Send the released identifiers, let the server apply verified scope, and reconcile neutral not-found outcomes without exposing why access failed.

PreviousPush and application lifecycleNext Channels, messages, and conversations
On this pageScope hierarchyWhere scope comes fromClient-side rule
Report a docs issue