API and MCP at a glance | ATX AnalyticsTable Docs

API and MCP at a glanceWhat the public REST API, headless metrics and MCP servers are for, who uses which, the one security model under all three, and where to start. ATX AnalyticsTable can be used from outside the application as well as from inside it. Three pieces make that possible, and all three run under the same roles, access rules, licence and audit trail as the desktop and server application — there is no second, weaker way in.

Overview

ATX AnalyticsTable can be used from outside the application as well as from inside it. Three pieces make that possible, and all three run under the same roles, access rules, licence and audit trail as the desktop and server application — there is no second, weaker way in.
REST API (/api/v1) — A versioned, documented HTTP API: read project tables with SQL, read saved connections, fetch dashboard data, call MCP tools. OpenAPI 3.1, RFC 9457 errors, rate limits, idempotency and cursor paging. — Scripts, schedulers, notebooks, other BI tools, Power Automate, data apps, AI agents
Headless metrics (/api/v1/metrics) — The governed semantic layer served over HTTP: ask for measures by dimensions and get the same numbers the dashboards show, with the SQL the planner wrote. — Anyone who would otherwise retype a metric definition — notebooks, spreadsheets, another BI tool, an LLM
MCP servers — ATX AnalyticsTable is a Model Context Protocol client. An administrator registers servers — BigQuery, PostgreSQL, Jira, Confluence, or any other — once, and their tools become available, read-only by default. — Ask Greg (when the data policy allows it), the REST API, and administrators testing a server in Settings

The REST API — what it is for

ATX AnalyticsTable has a public, versioned REST API under /api/v1 on the same address as the application. Scripts, schedulers, notebooks, other BI tools and AI agents can use it to read project tables with SQL, query governed metrics, fetch the data behind a dashboard widget, and call the tools of registered MCP servers. It is a facade over what the application already does, so the same roles, object grants, row- and column-level security, time limits and audit trail apply to every call.
It is READ-ONLY by design. SQL endpoints accept one read-only statement for every caller, administrators included, because a credential held by a script can leak. The machine-readable description is GET /api/v1/openapi.json (OpenAPI 3.1), and GET /api/v1/docs is a reference page. Settings → MCP servers & API can download the OpenAPI document.

Where to start

An integrator writing a script: read "The REST API", then "Conventions and errors". Ask your administrator for a scoped service token with the viewer role.
Someone who wants governed numbers in a notebook or another tool: read "Headless metrics".
An administrator connecting BigQuery, PostgreSQL, Jira or Confluence: read "MCP servers", then "MCP security and resilience".
An administrator letting Ask Greg use those systems: read "Ask Greg with MCP servers".
Whoever runs the server: "Operating the API and MCP" lists every setting, metric and audit record.
Anyone who prefers to watch first: the training film Ask Greg about BigQuery (AnalyticsTable → Training) sets up a BigQuery server, turns it on for Ask Greg and asks a question — in 1:19.
Offline or for a review pack: the PDF user manual, Appendix D, carries the same material — the REST API, headless metrics, MCP servers, every template parameter, Ask Greg with MCP and the installation settings.
Open the MCP servers & API screen: Settings → Settings → Set / Restore → MCP servers & API
The interactive reference, with every endpoint, parameter and response schema, is published at /products/analyticstable/developers/api-reference. A running installation serves its own copy at /api/v1/docs and the machine-readable document at /api/v1/openapi.json; both need a credential. Settings → MCP servers & API → Download OpenAPI document saves the document for an API gateway or a code generator.

Design principles

One security model — The API is a facade over the routes the application already uses. Sign-in (API token, Entra ID, scoped service tokens), roles, object-level grants, row- and column-level security, admission lanes, time limits, licence enforcement and the tamper-evident audit trail all apply unchanged.
Read-only by design — SQL endpoints accept one read-only statement for every role, administrators included. A credential held by a script can leak, and a leaked one should not be able to write. File-, path- and URL-reading SQL functions (read_csv, glob and the like) are refused.
Stable contract — v1 changes only by addition — new endpoints, new optional fields. A breaking change would go to /api/v2, run alongside v1 for at least two releases. Every response carries ATX-API-Version: 1.
Predictable errors — Every error is an RFC 9457 problem document with a stable code and a retryable flag.
Resilient clients — Rate-limit headers, Retry-After, Idempotency-Key, cursor paging and request ids give a client what it needs to retry safely.

Glossary terms on this page

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.