ATX AnalyticsTable Developer Docs | REST API, Headless Metrics & MCP

ATX AnalyticsTable for developersRead project data with SQL, query governed metrics, fetch dashboard data and call MCP tools — under the same security model as the application. The public REST API lets scripts, schedulers, other BI tools, notebooks and AI agents use an ATX AnalyticsTable installation: read project data with SQL, query governed metrics ("headless BI"), fetch dashboard data, and call the tools of registered MCP servers. All of it runs under the same security model as the desktop and server application. The API lives at /api/v1 on the backend — the same host and port as the application, behind your reverse proxy on a server installation — and describes itself in an OpenAPI 3.1 document.

Design principles

One security model — The API is a facade over the routes the application already uses. Access control (API token, Entra ID, scoped service tokens), RBAC 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, admins 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, …) are refused.
Stable contract — v1 changes only additively (new endpoints, new optional fields). Breaking changes go to /api/v2, which would 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 clients what they need to retry safely.

Endpoints at a glance

Twenty endpoints in five groups. The API reference has parameters, request and response bodies and a curl example for each.

GET — /api/v1 — Version, build, links
GET — /api/v1/openapi.json — OpenAPI 3.1
GET — /api/v1/docs — HTML reference
GET — /api/v1/me — Identity, role, permissions, rate limit
GET — /api/v1/health — Engine admission state, MCP circuit states; ok / degraded / draining
GET — /api/v1/tables — Tables of the project (X-Project-Path)
GET — /api/v1/tables/{name} — Columns of one table
POST — /api/v1/query — One read-only DuckDB statement on the project database, paged
GET — /api/v1/connections — Saved connections visible to the caller (id, name, kind, database only)
POST — /api/v1/connections/{id}/query — One SELECT/WITH on a saved connection, paged
GET — /api/v1/metrics — Metric catalogue (?kind=, ?q=)
GET — /api/v1/metrics/{id} — One metric; for measures, compatibleDimensions
POST — /api/v1/metrics/query — Headless metric query
GET — /api/v1/dashboards — Dashboards visible to the caller
GET — /api/v1/dashboards/{urn} — One dashboard definition
POST — /api/v1/dashboards/{urn}/widgets/{wid}/data — The data behind one widget
GET — /api/v1/mcp/servers — Registered MCP servers and their health
GET — /api/v1/mcp/templates — Ready-made MCP server definitions
GET — /api/v1/mcp/servers/{id}/tools — Tools, their classification and policy decision
POST — /api/v1/mcp/servers/{id}/tools/{tool}/call — Call one allowed tool

Where the API runs

Base path: /api/v1 on the backend — the same host and port as the application; behind your reverse proxy on a server installation. The API adds no new listener and no new port.
Machine-readable spec: GET /api/v1/openapi.json (OpenAPI 3.1) on your installation. The same document is published here: download OpenAPI 3.1.
Built-in reference: GET /api/v1/docs. It has no scripts and no external assets, so it also works on an air-gapped server.
One source of truth: the OpenAPI document, the built-in reference page and the API's contract test are all generated from the same catalogue in the product. An endpoint that is not described there fails the contract test.

How this maps to analyst evaluation criteria

Analyst evaluations of analytics and BI platforms, such as Gartner's Magic Quadrant and Critical Capabilities for Analytics and BI, ask for open, documented APIs, a reusable metrics/semantic layer that other tools can consume ("headless BI"), governance that applies to every access path, and agentic and AI interoperability. The API addresses those as follows:

The claim is about capability coverage, not a rating. Analyst firms publish their own assessments.

Documented, versioned, standards-based API — OpenAPI 3.1, RFC 9457 errors, IETF RateLimit and Idempotency-Key headers, /api/v1 versioning
Headless metrics / semantic layer as a service — GET /metrics, POST /metrics/query: governed definitions, declared joins, parameters, dialect-aware SQL
Governance on every path — The same RBAC, object grants, row/column security, licence, and audit as the UI, plus read-only SQL for every API caller
Enterprise identity — Entra ID tokens, scoped service tokens with their own roles, revocation without restart
Interoperability with AI agents — MCP client with BigQuery, PostgreSQL, Jira and Confluence templates. Ask Greg can use MCP tools when policy allows.
Operability — Health endpoint, Prometheus metrics, request ids, load shedding with Retry-After, circuit breakers for dependencies

Next — REST API — getting started
API reference — v1
Headless metrics — the semantic layer as an API
MCP servers
Download the OpenAPI 3.1 document
ATX AnalyticsTable handbook
ATX AnalyticsTable product page

Glossary terms on this page

ATX Institute on LinkedIn

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