What Realtime delivers
Realtime notifications are hints that something changed. Durable state remains available through the Platform API.
Connection flow
Authentication
Realtime accepts the supported instance-bound user session or RevoEngine API-key identity. Human sessions follow the same instance and organization security rules as HTTP requests. Service and API-key identities are checked against their current owner, restrictions, and platform access. The connection is authorized before tenant data is loaded. Current user roles and group membership determine which resource notifications can be delivered. For organization workspaces, the short-lived instance session also applies to Realtime. A socket cannot outlive the applicable authorization lifetime. Account disable, deletion, or platform-access removal disconnects matching live clients when the security change propagates.Client messages
The protocol has a small set of client commands:
Clients cannot subscribe to arbitrary server channels. Channel admission is constrained by the product capability and the caller’s access.
Server messages
Outbound messages are grouped into:REALTIMEfor application-defined live messages;EVENTfor managed resource lifecycle changes;ACTIVITYfor operational and collaboration activity.
Reconnect correctly
Networks, browser sleep, authorization refresh, and service maintenance can all interrupt a socket. A production client should:- Detect close and error states.
- Refresh expired authentication through the normal auth flow.
- Reconnect with bounded exponential backoff and jitter.
- Rejoin required supported channels.
- Reload active views from the Platform API.
- Resume transient presence only after membership is restored.
Ordering and duplicates
Realtime is not a durable ordered event log. A client can observe duplicates, coalesced updates, or a gap during reconnect. Apply these rules:- identify resources by stable ID;
- compare the resource version when available;
- make event application idempotent;
- ignore an older update after a newer version is already visible;
- refetch after reconnect instead of replaying assumptions locally.
Publish from low-code
Components can publish an application message to the supported Realtime channel:High-level backend mechanism
Each connected client belongs to one Realtime process. Cross-process publication distributes a resource or activity signal to every process that may own matching sockets. The final dispatcher applies instance, user, group, role, channel, and thread ownership filters before sending. Connection membership and short duplicate-suppression windows are transient. Durable resource and event history remains in the control plane and should be queried after reconnect.Production checklist
- Use Realtime as invalidation and presence, not durable storage.
- Authenticate with the same instance identity used for HTTP access.
- Reconnect with bounded backoff and refresh credentials when required.
- Rejoin supported channels after reconnect.
- Refetch authoritative state after a connection gap.
- Make handlers version-aware and idempotent.
- Keep messages compact and free of secrets.
- Persist business state before publishing its notification.
- Use Automation Events when replay and durable fan-out are required.
Related guides
Automation Events
Trigger durable, replayable workflows from business events.
Authentication
Establish an instance-bound user or service identity.
Observability
Correlate execution and lifecycle evidence after an update.
Runtime API
Publish compact application messages from Components.

