Use casesPartners and pipelinesLive dashboards06 / 12
How it fits together

Every run, to whoever may see it

A call through any front door is recorded as it completes: one history row and one event, in the same batch. A separate events server reads every instance's events from the shared store and streams each one, over plain HTTP, only to the keys allowed to see it.

9,000streams in one process, measured
0.75 sfor an event to reach all of them
24 ha client can resume from
Runs happen
The governed core
Shared store
Events server
Who watches
↗

Partner backend

GET /q/orders_by_customer
source: rest
↗

AI agent

tools/call orders_summary
source: mcp
↗

Nightly export

nightly_orders → s3://
source: export
The governed core↗
× each instance 01020308
Identity · who is asking
Policy · what they may see
Execution · run, mask, format
08 · Record it
One history row and one event, in the same batch

The same core as on Home: these runs were governed first.

↗

Event log

shared store

One event per run, kept 24 h by default, whatever run history keeps.

PostgreSQLNOTIFY · wakes it at once SQLitepolled every 1 s ClickHouse run storepolled · 1 s settleExp↗
↗ queryapigate events Stable own port · /events behind your proxy
key checked, and again every 60 s✓ a key sees its own runs; admin sees all✓ filters narrow, never widen✓ resume with Last-Event-ID✓
↗

Ops screen

admin · every run
export nightly_orders 2,310 rows 1.4 srest orders_by_customer 38 rows 12 ms
↗

Partner portal

key partner-acme · its own runs
rest orders_by_customer 41 rows 14 msrest orders_by_customer 38 rows 12 ms
↗

Failures board

admin · ?status=error
mcp orders_summary error timeoutrest orders_by_customer error timeout
What arrivesone frame per run: the record, never a row's values
id: 4182 source rest query orders_by_customer v1 status success rows 38 12 ms key partner-acme
Stablecompatibility promise Expmay change in a minor release Or GET /events on the main server: no extra process, up to 4 streams, its own process only, no resume.
Runs happenApps, partners, AI agents and exportsEvery run through a front door is recorded, with source set to rest, mcp or export.
The governed coreIdentity → policy → execution → recordEach run is recorded as it completes: one history row and one event, in the same batch, on every instance.
Shared storeThe event logKept 24 h by default. PostgreSQL wakes the events server at once; SQLite and the ClickHouse run store (experimental) are polled every second.
Events server Stablequeryapigate eventsThousands of streams per process. A key sees its own runs, the admin key sees all, and filters only narrow.
Who watchesOps screens, partner portals, failure boardsEach gets frames with who, which query, status, rows and timing, never a row's values.

The same governed core as the full architecture.

For operations screens

A live view of what is being queried, by whom

A wall display or a client that reacts when a query runs. GET /events streams each run as it completes, per key if you want, fanned out across instances by the events server.

✓Server-sent events over plain HTTP: a fetch stream in the browser with the key in a header, no WebSocket infrastructure.
✓Per-key feeds, so a partner can watch their own calls and nobody else's.
✓Across several instances, queryapigate events reads every instance's runs from the shared store, woken by a PostgreSQL notification.
✓Stable since 0.34, under the compatibility promise. Filter by query, connection, kind or status.
Live dashboards
# in the browser: the key goes in a header, never the URL
const res = await fetch("https://data.example.com/events", {
  headers: {"X-API-Key": key}
})
const reader = res.body.pipeThrough(new TextDecoderStream()).getReader()
for (let buf = ""; ;) {
  const {value, done} = await reader.read(); if (done) break
  const frames = (buf += value).split("\n\n"); buf = frames.pop()
  for (const f of frames) {
    const line = f.split("\n").find(l => l.startsWith("data: "))
    if (line) onRun(JSON.parse(line.slice(6)))
  }
}

# what arrives, one frame per run
id: 4182
data: {"type": "query.run", "source": "rest", "kind": "saved",
       "query": "orders_by_customer", "version": 1, "connection_name": "shop",
       "entry": {"status": "success", "rows": 38, "duration_ms": 12,
                 "key_name": "partner-acme", ...}}
More use casesAll twelve →

Not sure which fits?

The example APIs ship with a generated database and one scoped key per scenario, so you can try each of these in a few minutes without connecting anything of your own.

Run the examplesCompare alternatives