Data-Plane API

The data plane (/v1/*) is what your applications and end users talk to. It’s addressed per project and authenticated with per-project API keys or a user JWT — not management credentials.

Base URL & auth

https://<host>/v1

Send your project key in apikey, and (for a signed-in user) the JWT in Authorization:

apikey: anvilbase_anon_<slug>_…
Authorization: Bearer <user-jwt>     # optional

Scope	Credential	RLS
anon	anon key	enforced (public rows)
authenticated	anon key + user JWT	enforced (user’s rows)
service_role	service_role key	bypassed

With the Supabase SDK, the base URL is https://<host>/v1/<project_id>.

REST (REST→SQL engine)

/v1/rest/<project_id>/<table>

Method	Action
GET	read rows (Reading Data)
POST	insert (Modifying Data)
PATCH	update (filter required)
DELETE	delete (filter required)
POST /rpc/<fn>	call a function (RPC)

Query syntax (filters, select, order, limit, offset) is in REST Query Syntax. Headers: Prefer: return=representation, Prefer: count=exact, Accept: application/vnd.pgrst.object+json.

Raw SQL: POST /v1/rest/<id>/rpc/exec_sql (service_role only) — see SQL Editor.

Auth

/v1/auth/<project_id>/*

Method	Path	Purpose
POST	sign-up	{email, password}
POST	sign-in	{email, password} → access_token (JWT)
POST	sign-out	end session
GET	session	current session
POST	magic-link	{email}
GET	oauth/<provider>	OAuth redirect

See Auth.

Storage

/v1/storage/<project_id>/*

Method	Path	Purpose
PUT	object/<bucket>/<path>	upload
GET	object/<bucket>/<path>	download
DELETE	object/<bucket>/<path>	delete
POST	object/list/<bucket>	list
POST	object/sign/<bucket>/<path>	signed URL ({expires_in})

See Storage.

Queues (PGMQ)

A server-side queue surface over PGMQ — service_role only (anon / authenticated keys get 403). Native shape /v1/queue/<project_id>/...; the SDK alias (client.queues) is /v1/<project_id>/queue/v1/....

Method	Path	Purpose
POST / GET	queue/<project_id>/queues	create ({name}) / list
DELETE	queue/<project_id>/queues/<name>	drop a queue
POST	queue/<project_id>/queues/<name>/send	enqueue one ({message, delay?})
POST	queue/<project_id>/queues/<name>/send_batch	enqueue many ({messages: [...]})
POST	queue/<project_id>/queues/<name>/read	read with a visibility timeout ({vt, qty?})
POST	queue/<project_id>/queues/<name>/pop	read + delete one atomically
POST	queue/<project_id>/queues/<name>/ack	delete a message ({msg_id})
POST	queue/<project_id>/queues/<name>/archive	move a message to the archive ({msg_id})
GET	queue/<project_id>/queues/<name>/archived	list archived (DLQ-equivalent)
POST	queue/<project_id>/queues/<name>/replay	re-send an archived message ({msg_id})
GET	queue/<project_id>/queues/<name>/metrics	queue length + message ages

PGMQ has no separate dead-letter queue — archive is the DLQ-equivalent. See Queues.

Cache (Valkey)

A server-side KV surface over Valkey — service_role only. Every op runs as the project’s per-project ACL user, physically confined to the <project_id>:* keyspace. Native shape /v1/cache/<project_id>/...; the SDK alias (client.cache) is /v1/<project_id>/cache/v1/....

Method	Path	Purpose
GET	cache/<project_id>/get/<key>	get a string
POST	cache/<project_id>/set	set ({key, value, ex?, px?, nx?, xx?} — ex wins over px)
POST	cache/<project_id>/del	delete keys ({keys: [...]})
POST	cache/<project_id>/incr	increment ({key, by?})
POST	cache/<project_id>/decr	decrement ({key, by?})
POST	cache/<project_id>/expire	set TTL ({key, seconds})
GET	cache/<project_id>/ttl/<key>	remaining TTL
GET	cache/<project_id>/exists/<key>	existence check
POST	cache/<project_id>/mget	multi-get ({keys: [...]})
POST	cache/<project_id>/mset	multi-set ({pairs: {k: v}})
GET	cache/<project_id>/scan	iterate keys (?cursor=, ?match=, ?count=)

Keys are bare in requests/responses — the <project_id>: prefix is added for you. See Cache.

Cron (pg_cron)

A server-side scheduled-jobs surface over pg_cron — service_role only. Each job runs inside the project’s database and is namespaced + tenant-isolated. Native shape /v1/cron/<project_id>/jobs...; the SDK alias (client.cron) is /v1/<project_id>/cron/v1/jobs.... (The console reads jobs via the admin Management API.)

Method	Path	Purpose
POST / GET	cron/<project_id>/jobs	schedule ({name, schedule, command}) / list
DELETE	cron/<project_id>/jobs/<name>	unschedule a job
GET	cron/<project_id>/jobs/<name>/runs	recent run history, newest-first (?limit= ≤ 100)

schedule is a 5-field cron expression or a pg_cron interval (e.g. 5 seconds); command is SQL run in the project DB on that schedule. See Cron & Scheduling.

Edge functions

POST /v1/functions/<project_id>/<name>

Invokes a deployed function. verify_jwt: true (default) requires a token. The runtime receives injected X-AnvilBase-* context headers. See Edge Functions.

Realtime

ws(s)://<host>/v1/realtime/<project_id>/socket/websocket?token=<jwt>&vsn=2.0.0

Phoenix Channels — postgres changes, broadcast, presence. Auth via the token query param. See Realtime.

eIDAS (optional)

/v1/eidas/<project_id>/*

Method	Path	Purpose
POST	verify	start an OpenID4VP verification
POST	verify/callback	submit the wallet’s VP token
POST	issue	create a credential offer (OpenID4VCI)
GET	.well-known/openid4vp	verifier metadata
GET	.well-known/openid-credential-issuer	issuer metadata

See eIDAS.

Rate limits

Per project, per scope:

Scope	Limit / 60s
anon	100
authenticated	1,000
service_role	5,000

Responses include X-RateLimit-Limit, X-RateLimit-Remaining, and (on 429) Retry-After. Per-project DB pool exhaustion also returns 429 with Retry-After: 1.

Errors

{ "error": "invalid query", "statusCode": 400, "hint": "...", "details": "..." }

See Error Codes. Management endpoints (/api/v1) are documented separately in Management API.