Skip to main content
This is the current version of Realtime. If you’re looking for the original Workspace Settings–based Realtime — channel permission rows and channel triggers — see Realtime (Legacy). Legacy Realtime is not deprecated, and both systems can run side by side. See Legacy vs Realtime for a comparison.

​
What is Realtime?

Realtime is anything that lets your application deliver live updates without the client asking for them — a chat window, a collaborative document, a live dashboard, in-app notifications, or multiplayer state. Instead of polling an API on a timer, the client holds one open websocket connection and receives updates as they happen. In Xano, Realtime is a section of your workspace with the same shape as your APIs. A message is a named handler with typed inputs, a full function stack, and a response — the same authoring experience as an API endpoint, applied to a websocket.

​
The hierarchy

The Realtime hierarchy deliberately mirrors REST, so if you can build an API in Xano you already know how this works. You can create multiple realtime servers in a single workspace, each with its own connection address. That lets you separate concerns — a public notifications server and an internal collaboration server, for example — without them sharing configuration or access rules.

​
What you can build

Because a message is a real handler rather than a pass-through broadcast, the patterns that were impractical before become ordinary:
  • Chat with a stored transcript, presence, and per-recipient redaction
  • Collaborative editing, where each edit is validated before it fans out
  • Live dashboards fed by a scheduled task publishing to a channel
  • Multiplayer state, with typed path parameters identifying the room or match
  • Request/response over a socket — deliver the result back to the sender only
  • Streaming an LLM or agent response back over the same connection

​
Key capabilities

Every message declares a payload schema, so malformed payloads are rejected before any of your logic runs. From there it’s an ordinary Xano function stack: middleware, database calls, external requests, a response block, and DB Preview while you build.See Messages.
Channels are addressed by a path template — rooms/{room_id} — with declared parameter types (text, int, decimal, bool). Values read from a join acknowledgement or realtime.get_session.params can still be strings; validate or convert those transport values before using them.See Servers & Channels.
deliver_to decides who receives each message: channel for everyone on it, sender for just the client that invoked it, others for everyone but the sender, or explicit for clients you target yourself.The delivery guarantee — at_most_once or at_least_once — is set on the channel, with optional per-recipient tracking.See Delivery and Delivery guarantees.
Channels control publish policy, anonymous clients, presence, client-to-client addressing, and rate limiting. Individual messages can require authentication independently of the channel’s join policy. Who can build and edit Realtime in the builder is governed by the Workspace Realtime Features RBAC permission.See Access Control.
Five triggers across two scopes let you run logic at connection and channel boundaries — including vetoing a connection or a join, and rewriting or dropping an individual delivery.See Realtime Triggers.
realtime.publish injects a server-authored event onto a channel from any query, function, or task — so a background task, a database trigger, or an API endpoint can drive a live update. It’s the v2 counterpart to the legacy api.realtime_event function, and the two are not interchangeable.See Publishing from Xano.

​
The same workflow as the rest of Xano

Realtime is not a separate subsystem with its own rules. It is authored in the same editors and follows the same governance path as everything else in your workspace:
  • Drafts and publish, so changes don’t go live on save
  • Branches and diffs, and version history
  • Run & Debug for testing a message handler without a client attached
  • A Messages tab in Request History, with its own retention controls
  • Canvas, stack, XanoScript, and split-screen authoring
  • CLI push and pull, a dedicated Realtime export, and editor support from the XanoScript Language Server extension
Your realtime logic is a portable artifact — XanoScript that pushes and pulls through the CLI and is diffable in Git — so there’s no second toolchain to learn just to put logic behind a websocket.

​
Connect a client

Use the V2 server’s canonical with the /ws/ WebSocket route. Wait for a successful join acknowledgement before invoking a message handler. See Connecting a Client for a complete native WebSocket example, authentication, and connection troubleshooting.

​
Next steps

Servers & Channels

Create a realtime server, get its connection address, and define channels.

Messages

Write a message handler, declare its payload, and control delivery.

Access Control

Decide who can connect, join, publish, and receive.

Realtime Triggers

Run logic on connect, disconnect, join, leave, and deliver.