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
Correctness model

Delivery, ordering, and reconciliation

Design clients for atomic outbox writes, at-least-once events, sequence gaps, reconnect, and ambiguous mutations.

Updated 2026-08-09•docs/realtime/v1 · TRANSACTION_IDEMPOTENCY_OUTBOX_STANDARD.md

Write path

  1. The API validates the principal, exact scope, resource policy, bounds, and expected versions.
  2. The domain change and durable outbox record commit atomically in MongoDB.
  3. A worker later publishes authorized realtime and webhook projections.
  4. Consumers deduplicate stable identities and reconcile a channel sequence gap through REST.

What is and is not guaranteed

PropertyBoundary
Durable mutation + event intentAtomic inside the owning transaction/outbox boundary
Event deliveryAt-least-once; duplicates are possible
Channel orderingMonotonic eventSequence for promised durable channel events
Presence and typingEphemeral, TTL-bound, best-current-state only
Client offline writesNot persisted or automatically replayed by the released SDKs
Exactly-once processingNot claimed; consumers use deduplication and reconciliation

Ambiguous mutation outcome

Read before replay

A timeout or transport failure does not prove the server rejected a mutation. Read the fixed-identity resource, compare the retained state/version or idempotency binding, and retry only when the documented contract says it is safe.

Sequence gap or stale subscription

  1. Stop treating local channel continuity as authoritative.
  2. Use the SDK recovery result or the documented current-state REST reads.
  3. Merge confirmed entities by their independent versions and apply tombstones.
  4. Resume event processing only from the server-acknowledged recovered baseline.
PreviousChannels, messages, and conversationsNext Integration security checklist
On this pageWrite pathWhat is and is not guaranteedAmbiguous mutation outcomeSequence gap or stale subscription
Report a docs issue