Docs

Everything here talks to the same API your own console uses — nothing agent-only, nothing hidden. Every call is scoped to one database and shows up in that database's activity log.

MCP setup

Point Claude Desktop, Cursor, or any MCP-compatible client at your database. Get the exact config (with your real API key already filled in) from your console’s Agent & MCP tab — this is the shape of it:

{
  "mcpServers": {
    "stashi": {
      "command": "npx",
      "args": ["-y", "@stashidb/mcp-server"],
      "env": {
        "STASHI_API_KEY": "st_live_...",
        "STASHI_DATABASE_ID": "DB_...",
        "STASHI_API_URL": "https://www.mystashi.online"
      }
    }
  }
}

Nine tools ship with it: list_tables, describe_table, run_query, create_checkpoint, rollback_last_checkpoint, create_branch, create_agent_key, store_memory, and search_memory.

Remote MCP (HTTP-based clients)

For remote clients and webhooks that connect over public HTTPS, Stashi provides an MCP endpoint using the Streamable HTTP transport. Two authentication options are supported:

Header-based authentication:
URL:   https://www.mystashi.online/mcp
Auth:  Authorization: Bearer <your STASHI_API_KEY>

URL-based authentication (e.g. ChatGPT Developer mode):
URL:   https://www.mystashi.online/mcp/<your STASHI_API_KEY>
Auth:  None (the key in the URL serves as the credential)

In ChatGPT: Settings → Security and login → Developer mode, then Plugins → + → paste the URL and select “No Auth.” Both URLs are also available on your database’s Agent & MCP tab in the console. The endpoint automatically resolves the target database from the provided key on every call.

Account-wide MCP (multiple databases, one connection)

An account key reaches every database you own through a single connection. Generate one from your database’s Agent & MCP tab under “Connect once, reach every database”:

URL:   https://www.mystashi.online/mcp/<your account key>
Auth:  None (the key in the URL serves as the credential)

The tool set gains a tenth tool, list_databases (id, name, plan, status, region for everything on the account), and the other nine each take a required databaseId argument instead of it being fixed to the connection. The usual pattern: call list_databases once, then pass whichever id you need on every subsequent run_query, create_checkpoint, etc. Same auto-checkpointing on destructive statements and same audit log per database — nothing pooled or shared between them, just addressed by id instead of baked into the URL.

Account keys carry the same full/read-only scope as per-database scoped keys, and the same rule for who can create one: a full key minting another key isn’t privilege escalation (neither can exceed the account’s own access), so an agent holding a full account key can mint itself narrower keys for subagents without you in the loop. Revoking an account key cuts off access to every database at once — reconnecting an existing ChatGPT/Claude connector to the account-wide form means adding it as a new connector, not editing the old per-database one in place.

Running a query without MCP

No SDK to install — the same API key works over plain HTTP. This is exactly what the MCP server calls under the hood.

curl -X POST https://www.mystashi.online/api/databases/DB_xxx/query \
  -H "Authorization: Bearer st_live_..." \
  -H "Content-Type: application/json" \
  -d '{"sql": "select id from orders where status = '"'"'pending'"'"' limit 50"}'

# Python — plain requests, no SDK
import requests

resp = requests.post(
    "https://www.mystashi.online/api/databases/DB_xxx/query",
    headers={"Authorization": f"Bearer {STASHI_API_KEY}"},
    json={"sql": "select id from orders where status='pending' limit 50"},
)
print(resp.json()["rows"])

// TypeScript / JavaScript — plain fetch
const res = await fetch(
  `https://www.mystashi.online/api/databases/${databaseId}/query`,
  {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.STASHI_API_KEY}` },
    body: JSON.stringify({ sql: "select 1" }),
  }
);
const { rows } = await res.json();

Dev plan schema isolation

Dev databases use a pooled tenancy model. Multiple Dev databases share the same physical PostgreSQL database, but every tenant receives its own PostgreSQL role and its own schema. Stashi sets that schema as the role's default search_path, so ordinary unqualified SQL such as CREATE TABLE users (...) is created inside that tenant schema automatically.

Applications on the Dev plan should avoid hard-coding the public schema in migrations or ORM configuration. Statements such as CREATE TABLE public.users (...)or REFERENCES public.users(id) bypass the tenant's assigned schema and will normally fail with a permission error. This is expected and is part of Stashi's isolation boundary.

-- Portable across Stashi Dev and isolated plans
CREATE TABLE users (
  id uuid PRIMARY KEY,
  email text NOT NULL UNIQUE
);

-- Avoid on pooled Dev databases
CREATE TABLE public.users (
  id uuid PRIMARY KEY,
  email text NOT NULL UNIQUE
);

Most ORMs work without changes when they emit unqualified table and type names. If your migration tool generates explicit public. qualifiers, configure it to use the connection's current schema or remove those qualifiers before applying migrations. Starter, Production and Dedicated databases use isolated databases, but schema-agnostic migrations remain the recommended approach because the same migration set can move between plans safely.

Checkpoints & rollback

Any statement that looks destructive — schema changes, TRUNCATE, an unfiltered DELETE or UPDATE — triggers an automatic checkpoint first, and the statement waits for it to finish before running. You can also save one on demand:

curl -X POST https://www.mystashi.online/api/databases/DB_xxx/checkpoints \
  -H "Authorization: Bearer st_live_..." \
  -H "Content-Type: application/json" \
  -d '{"label": "before pricing migration"}'

# and to undo the most recent one:
curl -X POST https://www.mystashi.online/api/databases/DB_xxx/checkpoints/CP_ID/restore \
  -H "Authorization: Bearer st_live_..."

Scoped agent keys

A full-access key can mint additional keys for subagents — read-only by default, each one revocable on its own and labeled separately in the activity log.

curl -X POST https://www.mystashi.online/api/databases/DB_xxx/keys \
  -H "Authorization: Bearer st_live_..." \
  -H "Content-Type: application/json" \
  -d '{"label": "research-subagent", "scope": "readonly"}'

Questions this page doesn’t answer: contact us.