Agents now connect to datahashi over OAuth — scoped tokens, no API keys to paste
datahashi
Open console
← Docs

Getting started

Publish your first governed model and query it from the console, REST, or MCP — locally with Docker or from the hosted console.

Updated

There are two ways in: run the stack locally with Docker, or start from the hosted console. Both end at the same place — a published model and a first governed query you can trust from a dashboard and an agent.

Beachhead path: connect Snowflake or BigQuery, publish a few metrics, then hit the same metric names from REST and MCP.

Local, with Docker

Docker is the only hard requirement — the Go services build and run in containers. (A Go 1.26+ toolchain with CGo is optional, for a faster edit-test loop.)

Bring it up

make up      # api :8080, engine :8081, control-plane db, sample warehouse

This starts two processes on purpose:

  • hashi-api — the control plane. Browser-reachable; holds the key that seals warehouse credentials. Never runs SQL.
  • hashi-engine — holds the live warehouse connection and compiles SQL. Never exposed to a browser.

Drive the whole flow

make smoke   # author -> publish -> governed rows, end to end

If that prints rows, every seam is wired: the control plane compiled a model, published an artifact, proxied a query with a principal attached, and the engine ran it against the sample warehouse.

make down    # tear it down

From the console

  1. Create a workspace. Sign in and create a workspace (called an org in the API). It is the isolation boundary for your sources, models, and credentials.
  2. Connect a source. Register a warehouse — Snowflake or BigQuery preferred for production beachhead; also Postgres, MySQL, or DuckDB. The connection string is sealed at rest; datahashi never widens the access the credential already has.
  3. Author a model. A model is YAML: entities (your business nouns), dimensions and measures on those entities, and metrics built from measures. Apply draft validates it; publish freezes it. Start with three metrics you’d trust an agent to speak aloud.
  4. Mint a credential. Issue a data-plane key scoped to a principal — governed (named metrics and views; the default for agents and apps) or explore (raw measures and dimensions for internal analysis).
  5. Query it. Send a Semantic Query to the engine with your bearer token — from the playground, REST, or MCP. Same metric names everywhere.
curl "$ENGINE/v1/query" \
  -H "Authorization: Bearer $DATAHASHI_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "metrics": ["revenue"], "dimensions": ["Order.region"] }'

Agents over MCP

Connect an agent with a credential the control plane issued (OAuth / short-lived token — no long-lived warehouse key in a config file). The agent picks names from the catalog and sends the same Semantic Query shape. It never gets freeform SQL against your warehouse.

Success check: the playground (or BI) and the agent return the same number for the same metric.

Next: Write your first model · MCP guide.