Realtime · WS

Build on the exact feed the dashboard uses

Gli stessi eventi live che usa la dashboard — inviati nell’istante in cui accadono.

A single realtime channel spine pulses INSERT and UPDATE events left to right; branch lines deliver the same event tick at the same instant to three subscribers — a monitoring chart, a bot and an alert bell — under channel chips named ws:workspace, devices and audit, over the wss endpoint address. ws:workspace devices audit INSERT UPDATE INSERT wss://api.busymate.net/realtime/v1
supabase-js — sottoscrivi il firehose
ts
import { createClient } from "@supabase/supabase-js";

const supabase = createClient("https://api.busymate.net", PUBLISHABLE_KEY, {
  global: { headers: { Authorization: `Bearer ${oauthToken}` } },
});

supabase
  .channel("ws:<workspace_id>")
  .on("broadcast", { event: "entry" }, ({ payload }) => {
    console.log("new request", payload.method, payload.url, payload.status);
  })
  .subscribe();

Perché Realtime

Push, never poll

Push-driven da un capo all’altro. Iscriviti dal tuo codice nel momento in cui cambiano traffico, stato o audit.

Il firehose delle entry

Ogni richiesta catturata viene trasmessa nell’istante in cui arriva — sullo stesso canale che la dashboard stessa consuma. Il tuo monitor vede ciò che vede il team, nello stesso istante.

I cambiamenti delle tabelle come stream

Dispositivi, impostazioni, tag, service group, la board to-do condivisa — tutto consegnato come eventi postgres_changes. Se è cambiato nel database, lo vieni a sapere. Niente timer, niente cicli di refresh.

Più che traffico

Anche l’audit trail live, il progresso degli import di memoria e gli eventi di controllo dei dispositivi sono sottoscrivibili. Costruisci bot di alerting, dashboard a parete o automazioni che reagiscono alla piattaforma stessa.

Sottoscrivi dalla documentazione

L’esploratore WS nella dashboard si unisce a canali reali col tuo token e formatta gli eventi man mano che arrivano. Guarda il feed prima di scrivere una sola riga di codice.

How it works

Subscribe once, stay current

Realtime-not-polling is a standing engineering rule here — every feature is push-driven end to end, and the dashboard itself never polls.

  1. 01

    Connect once

    One WebSocket to api.busymate.net's Realtime service, authenticated with the same OAuth token as REST and MCP.

  2. 02

    Join channels

    Subscribe to topics — a workspace firehose, a single device, fleet-wide status — each authorized by the same row-level security as the tables themselves.

  3. 03

    Events push to you

    Database triggers broadcast changes the instant rows land. No polling loop, no missed window between polls — the push IS the source of truth arriving.

  4. 04

    React — or publish back

    Feed alerting, wall dashboards and bots — or drive control flows the other way, like continuing a paused breakpoint over the proxy-control channel.

postgres_changes — table events
ts
// Raw table changes — the shared to-do board
supabase
  .channel("todos:all")
  .on(
    "postgres_changes",
    { event: "*", schema: "public", table: "todos" },
    (change) => console.log(change.eventType, change.new),
  )
  .subscribe();

The channels

A map of the live topics

The channels your code can join — the same canonical list the in-dashboard WS explorer documents and subscribes.

ws:<workspace_id>broadcast

The workspace entries firehose — every captured request from every device, the moment it lands. The exact channel the dashboard feed renders.

ws:<workspace_id>:<owner_user_id>broadcast

The same firehose narrowed to one owner's devices — what a non-operator account subscribes.

device:<uuid>broadcast

Per-device control plane: settings pushes, VPN and unpair commands, browser and farm command round-trips, live-activity messages.

devices:alldb

Device renames, pairing and status changes, fleet-wide — the reason device lists everywhere update without a refresh.

proxy-controlbroadcast

Dashboard ↔ proxy control flow: continue a request paused at a breakpoint, or resend a captured request.

settings:global · settings_device:all · settings_user:alldb

Settings pushes at every tier — capture engines refetch their effective settings the moment any layer changes.

service_groups:alldb

Service-group membership and rule changes, so grouped devices re-apply rules live.

breakpoint_events:alldb

Every request pausing and resuming at a breakpoint, as it happens — the read side of the continue flow.

audit:all · audit:<actor_uuid>db

The live audit trail — every action by every human and agent, fleet-wide for operators or scoped to your own events.

todos:allpostgres_changes

The shared to-do board as raw table-change events — the simplest channel to start with.

What teams build

React in real time

Alerting bots

Watch the firehose for error spikes on a production host and page your team the second they start — not on the next poll.

Wall dashboards

Render live traffic, device fleet state and the audit trail on a NOC screen — the same push the product dashboard consumes.

Reactive automation

React to a device going offline, a breakpoint pausing, or a settings change — then act back through MCP or the proxy-control channel.

One platform, five surfaces

Push is one of five surfaces

Every capability aligns across the dashboard, MCP, REST, WebSockets and BusyBro — a standing rule, checked on every ship. Read over REST, subscribe over WS, act over MCP: one identity, one permission model.

FAQ

Before you subscribe

What do I connect with?

supabase-js is the shortest path (it handles the Realtime protocol, auth and reconnection), but any client that speaks the Supabase Realtime protocol over WebSockets works. Authenticate with the same OAuth token as REST and MCP.

Broadcast vs postgres_changes — what's the difference?

Most channels are database-triggered broadcasts: a trigger fans a shaped payload to a named topic the instant a row lands — scalable and authorized per topic. A few simple tables (like the to-do board) stream raw postgres_changes events instead.

Can I publish, or only subscribe?

Both. Subscriptions cover the feeds; control flows publish back — the proxy-control channel carries breakpoint-continue and resend-request, and the confirm-gated MCP tools publish device commands on your behalf.

Will I see other people's traffic?

No — channel access is authorized by row-level security on the Realtime layer. Plain accounts get their own devices' feed; the fleet-wide firehose and audit stream require operator capabilities.

Why not just poll the REST API?

Realtime-not-polling is a standing engineering rule here: every feature is push-driven end to end, and the dashboard itself never polls. Push gives you lower latency, no missed events between polls, and no wasted queries.

Wire up the live stream

Canali e formati dei payload nella documentazione — o iscriviti dall’explorer nella dashboard.

Ask your mate