Realtime that ships business outcomes, not infra work

Xshathra helps product teams launch and grow revenue-driving realtime features faster: multiplayer game loops, chat and collaboration, social presence, live dashboards, and operational alerts. Instead of building and maintaining socket infrastructure, your team focuses on product behavior while Xshathra handles the realtime backbone under one host.

In practice: your backend mints short-lived JWTs and publishes authoritative events, clients connect to /realtime, and each project gets isolated keys for safer multi-environment rollout.

Why teams choose Xshathra

Ship faster: production-ready token, publish, and WebSocket paths out of the box.
Reduce risk: keep engine secrets server-side and use short-lived JWTs for connection/subscription auth.
Scale clearly: project-level API keys and channel contracts make environments and tenants easier to separate.
Operate simply: same-origin realtime (/realtime) avoids fragmented client networking.

From idea to production in four steps

Create a project in the console and copy server_api_key and client_api_key. Use server_api_key only on trusted backends; never ship it to browsers or game binaries. Use client_api_key where you identify the client to Xshathra per your integration guide.
Connect clients to wss://your-app.example/realtime/connection/websocket (local dev: ws://localhost:3001/realtime/connection/websocket). Put that full WebSocket URL in NEXT_PUBLIC_XSHATHRA_REALTIME_URL for browser bundles, or build it from window.location in your app.
Issue connection tokens from your API after you know who the user is: short-lived JWTs the client passes when opening the socket. Optionally use subscription tokens so users only join channels they are allowed to use.
Name channels and messages for your domain (e.g. one channel per room or match), then subscribe from clients and publish from your server when you need authoritative broadcasts.

Technical model (what runs where)

Your backend returns short-lived tokens to authenticated clients using first-party Xshathra endpoints. Clients connect on the same host as your app under /realtime. Server-side publish uses POST …/api/realtime/publish with project server_api_key.

// 1) Backend mints a connection token from Xshathra
const { token } = await fetch("https://app.example.com/api/realtime/token", {
  method: "POST",
  headers: {
    Authorization: "apikey " + process.env.XSHATHRA_SERVER_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ userId }),
}).then((r) => r.json());
// WebSocket URL = same host as your app + /realtime/connection/websocket
const wsUrl = "wss://app.example.com/realtime/connection/websocket";

// 2) Connect to wsUrl with the token (use the client library pattern from /docs/clients)
// 3) Subscribe to channels, e.g. "chat:room:" + roomId

// 4) Backend: publish via Xshathra publish endpoint
await fetch("https://app.example.com/api/realtime/publish", {
  method: "POST",
  headers: {
    Authorization: "apikey " + process.env.XSHATHRA_SERVER_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    channel: "chat:room:" + roomId,
    data: { type: "message", text, fromUserId },
  }),
});

Token shapes and channel rules are covered in the guides below. You only need your console keys and the public /realtime URLs — no separate realtime vendor to configure.

Guides and examples

Each page focuses on contracts you implement: URLs, tokens, channels, payloads, and safe patterns, with production-minded defaults and copy-ready snippets.

Centrifugo — engine concepts, JWTs, channels, links to official docs

Realtime that ships business outcomes, not infra work

Why teams choose Xshathra

From idea to production in four steps

Technical model (what runs where)

Guides and examples

Client integration

Chat example

Game & matchmaking

API reference

Centrifugo