Drive it from
your own
Claude Code.

What TableBI does, and what your agent does

TableBI gives you trustworthy numbers — it does the data cleaning, the unified metric definitions, and the freshness accounting — plus the lossless raw underneath. The reasoning runs on your own Claude Code. The line is clean, and it never blurs.

Numbers come from the CLI, never from the model — so they're reproducible and traceable. Every --json payload carries a trust block: freshness per source, and the lineage (each metric's formula) to cite when you explain a result.

Connect once, kept synced

Live connectors are authorized once through the platform's own OAuth screen. After that, a source re-syncs when someone opens one of its dashboards and it has passed its cooldown (Google Ads 3 hours, Meta 6, GA4 12, Search Console 24), and a daily pass keeps the sources behind published dashboards fresh even when nobody opens them. Each refresh re-reads a trailing window, because every platform revises its recent days. The target you pick on the first connect persists. A CSV is one upload; upload again to add rows.

# provider = gsc | ga4 | google_ads | meta_ads; several targets → it lists them
tablebi connect google_ads -w acme
tablebi connect google_ads --account 1234567890 -w acme   # Google Ads
tablebi connect gsc --site "sc-domain:acme.com" -w acme    # Search Console

# pull again now; --days widens the window (pages and queries default to 90 days)
tablebi sync gsc --site "sc-domain:acme.com" --days 180 -w acme

# CSV: the label is yours — never the name of a platform that already syncs live
tablebi connect csv --file spend.csv --platform tiktok_ads -w acme

Data lags are real and TableBI accounts for them. Search Console is pulled as Google's fresh data, a few hours behind; the last two days are preliminary and Google revises them upward, so every sync re-pulls that range. GA4 keeps processing the most recent 24–48 hours. Meta keeps revising conversions after the click. Don't report "today" or "yesterday" as final — check freshness in context first.

Trusted numbers. Full granularity. Both.

Two altitudes over the same files. Your agent moves between them in one breath: unified metrics for the cross-channel story, raw when it needs a platform's own metric. The rows each connector pulls are kept as the platform reported them — you never trade trust for power.

Cross-platform blending always goes through the unified metrics view, never raw. Dimensions: date · platform · account · campaign (the live connectors sync at campaign level; Search Console's query / page / country / device stay in its own tables). Windows: last-7d · last-28d (default) · last-90d · last-<N>d · this-month · last-month · all · YYYY-MM-DD:YYYY-MM-DD, anchored on the last day that has data.

Pin a dashboard that refreshes itself

A pinned dashboard is a spec — declarative widgets — not a snapshot. Publishing hands back a hosted, read-only URL; the engine re-runs the query every time the data moves, so the link is always live. You build and edit it from Claude Code by editing the spec.

# create or update from a spec file, after a dry run that compiles and runs every widget
tablebi dashboard publish --file board.json --dry-run -w acme
tablebi dashboard publish dsh_7f2a… --file board.json -w acme

# inspect the current dashboard payload
tablebi dashboard show dsh_7f2a… -w acme --json

# build/edit: read the spec → edit JSON → save it back
tablebi dashboard spec dsh_7f2a… -w acme --json > /tmp/spec.json
tablebi dashboard set-spec dsh_7f2a… --file /tmp/spec.json --confirm -w acme

A spec is { version: 2, title, defaults: { view, window, filter, lang }, widgets: [{ kind, view, metrics, by, window, compare, filter, limit }] }, where kind is kpi · trend · breakdown · table · compare, plus sql as a marked escape hatch. Up to 12 widgets per dashboard. dashboard template starts you from the sources you connected; unpublish takes a link down. Without --confirm, set-spec only previews the change. The web UI renders whatever spec is saved; the entry point stays the agent, not a GUI.

Sources, kept connected

Connectors handle auth, incremental fetch and an encrypted credential vault, so each source stays live and refreshed — not imported once and forgotten. CSV is one-shot; the rest connect once via OAuth, then sync.

A CSV upload is tagged with a free-text --platform label and normalized into the same definitions — that is how channels without a live connector get in today. New sources implement one interface — auth plus incremental fetch — and inherit the unified normalization for free.

Claude Code or Codex. Your brain, your key.

TableBI ships the data and the deterministic engine; the reasoning runs on your own agent. The CLI is the primary surface — CLI-native agents are great at running commands and need no setup. tablebi install plants the skill so the agent learns the commands, the metric definitions, and the workflows.

A deterministic engine. No LLM inside.

"What happened" is plain, explainable computation — connectors pull raw data, normalization unifies the definitions, metrics derive once, and the same compiler serves query, ask and every dashboard. That's why a number is the same no matter how you ask for it.