> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Realtime

> Build websocket features in Xano the same way you build APIs — with servers, channels, and message handlers that each have their own function stack.

<Info>
  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)](/realtime/realtime-in-xano). Legacy Realtime is **not deprecated**, and both systems can run side by side. See [Legacy vs Realtime](/realtime/migrating-from-legacy-realtime) for a comparison.
</Info>

## 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.

| Realtime            | What it is                                                                         | REST equivalent |
| ------------------- | ---------------------------------------------------------------------------------- | --------------- |
| **Realtime Server** | What a client connects to. Has its own connection address (canonical).             | API group       |
| **Channel**         | What a client joins, addressed by a typed path template such as `rooms/{room_id}`. | API route       |
| **Message**         | The invocable handler inside a channel — typed inputs, function stack, response.   | API endpoint    |

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

<AccordionGroup>
  <Accordion title="A full function stack per message">
    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](/realtime/messages).
  </Accordion>

  <Accordion title="Typed channel paths">
    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](/realtime/realtime-servers-and-channels).
  </Accordion>

  <Accordion title="Per-message delivery control">
    `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](/realtime/messages#delivery) and [Delivery guarantees](/realtime/realtime-servers-and-channels#delivery-guarantees).
  </Accordion>

  <Accordion title="Access control at every level">
    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](/realtime/access-control).
  </Accordion>

  <Accordion title="Lifecycle triggers">
    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/realtime-triggers).
  </Accordion>

  <Accordion title="Publishing from anywhere in Xano">
    `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](/realtime/publishing-from-xano).
  </Accordion>
</AccordionGroup>

## 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](/maintenance-monitoring-and-logging/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](/vscode-ext)

Your realtime logic is a portable artifact — XanoScript that pushes and pulls through the [CLI](/xano-cli/push-pull) 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](/realtime/connecting-a-client) for a complete native WebSocket example, authentication, and connection troubleshooting.

## Next steps

<CardGroup cols={2}>
  <Card title="Servers & Channels" icon="signal-stream" href="/realtime/realtime-servers-and-channels">
    Create a realtime server, get its connection address, and define channels.
  </Card>

  <Card title="Messages" icon="message" href="/realtime/messages">
    Write a message handler, declare its payload, and control delivery.
  </Card>

  <Card title="Access Control" icon="lock-keyhole" href="/realtime/access-control">
    Decide who can connect, join, publish, and receive.
  </Card>

  <Card title="Realtime Triggers" icon="bolt" href="/realtime/realtime-triggers">
    Run logic on connect, disconnect, join, leave, and deliver.
  </Card>
</CardGroup>


## Related topics

- [Legacy Realtime vs Realtime](/realtime/migrating-from-legacy-realtime.md)
- [Realtime Triggers](/realtime/realtime-triggers.md)
- [Realtime Messages](/realtime/messages.md)