Metrics

Series

GET /api/metrics/series?window=1h

Authenticated, no channel capability — the response is scoped to the calling credential's account and cannot name another.

{
  "series": [
    {
      "accountId": "acc_…",
      "minute": 1710000000000,
      "nodeId": "node-1",
      "kind": "publish",
      "count": 412,
      "bytes": 88320
    }
  ],
  "windowMs": 3600000
}

One row per (minute, nodeId, kind). minute is epoch milliseconds at the minute boundary.

nodeId is in the identity, so sum across it. Two nodes counting the same minute produce two rows rather than overwriting each other; a chart that ignores nodeId and plots rows as points will show a sawtooth that is really just two nodes.

window

A raw number of milliseconds also works, clamped to between one minute and seven days. Anything unparseable falls back to one hour rather than erroring.

The window always ends now; there is no from parameter.

Live connections

GET /api/connections/count

{ "connections": 3204, "limit": 5000 }

This is the billing tenant's live total and its ceiling, in one call, whatever the organization's account count.

It exists separately from the per-account listings because it is the number the gateway enforces on. Summing /api/connections per account would neither match that number nor scale with the accounts a plan allows.

limit is null when no ceiling applies.

The listings

Three console-shaped endpoints, authenticated only, scoped to the account:

They read the answering node's own live state, so on a cluster each node reports its own. They are what the console draws; they are not a billing source.

There is no /api/status

It used to return a cross-account, since-boot total to any valid key — a small tenancy leak — and it is gone. /api/metrics/series replaced it, scoped to the caller's account.

If you find /api/status in an older integration, that is what to move it to.