Skip to main content
This is not the agntdata-provisioned workspace database. agntdata can provision a Supabase project for your workspace and expose it at /v1/db/* — that’s a separate, managed surface. This connection talks to your own Supabase organization using a Personal Access Token you generate in the Supabase dashboard. Use it to manage projects that live outside agntdata.

​
Overview

The Supabase connection proxies management requests to the Supabase Management API at https://api.supabase.com — enumerate projects, list and inspect edge functions, read secret names, and list database branches. Database access is not proxied through the Management API. When you grant per-table access in the dashboard, agntdata uses your Management API credential once to provision a scoped Postgres role on that project whose GRANTs match your grants exactly, then agents connect directly through that role. So reads/writes are enforced by real Postgres GRANTs — not by a privileged postgres proxy. Running SQL through the Management API endpoint is disabled.
  • Base URL: https://api.agntdata.dev/v1/connections/supabase/* (management ops)
  • Supabase auth: agntdata injects Authorization: Bearer <your_supabase_pat> for management ops
  • Credential: Supabase Personal Access Token (sbp_...) or OAuth, used only by agntdata to read project metadata and provision/maintain the scoped role
  • Database access: scoped Postgres role per project, surfaced to deployed agents as the connection_supabase_query / connection_supabase_schema MCP tools (each takes a project_ref)

​
Setup

1

Generate a Supabase Personal Access Token

In Supabase go to Account → Access tokens and create a PAT (sbp_...).
2

Paste it into agntdata

In the agntdata dashboard open Integrations, pick Supabase, and paste the PAT.
3

Call the Management API

Make requests to https://api.agntdata.dev/v1/connections/supabase/* with your agntdata API key. agntdata injects your PAT on every proxied request.
Supabase PATs are account-wide — they can read and modify any project in any organization your Supabase account belongs to. Treat the PAT like a root credential and rotate it from Account → Access tokens if you suspect it has leaked.

​
Examples

​
List projects you can see

​
Retrieve one project

​
Query a project database

Database access does not go through the Management API. After you grant per-table access at Integrations → Supabase, deployed agents query the project through the provisioned scoped role using the connection_supabase_query and connection_supabase_schema MCP tools — each takes a project_ref. POST .../database/query on the proxy is intentionally blocked (it would run as postgres).

​
List edge functions

​
Supported operations

  • Database — query / introspect via the per-project scoped role (connection_supabase_query / connection_supabase_schema MCP tools); enforced by Postgres GRANTs synced from your dashboard per-table grants
  • Projects — list, retrieve
  • Edge Functions — list, retrieve metadata
  • Secrets — list names (values are never returned)
  • Branches — list

​
When to use the workspace database instead

If you want a Supabase project managed by agntdata (provisioning, service-role key handling, row-level audit, SDK/MCP parity with the agent runtime), use the agntdata workspace database at /v1/db/* — no PAT required. See the /v1/db/* documentation for that surface.