The Data API

Every database base_create_database provisions also gets a Supabase-shaped Data API on by default — a PostgREST endpoint plus sherlock-backed auth — at:

https://api.shebang.pro/db/<slug>

Databases created before the Data API existed don't have one until you call base_enable_api — see enable on older databases.

Two keys, two trust levels

• publishable_key (sb_publishable_<slug>_…) is safe to ship in client code. Pair it with a signed-in user's sherlock session for row-level security to apply per-user.
• secret_key (sb_secret_<slug>_…) bypasses row-level security entirely — server-side only, never in a browser. It's shown once, at creation or enable time; if it's lost or compromised, rotate it with base_rotate_secret (see reload schema and rotate secret).

sherlock is the auth provider

Point supabase-js at the Data API like a normal Supabase project — createClient(api_url, publishable_key) — and calls like supabase.auth.signInWithPassword go through sherlock, the same identity provider behind every other shebang account. Row-level security policies read the signed-in user off auth.uid(), exactly as they would against a normal Supabase project.

RLS is off by default per table, same as a fresh Supabase project — a publishable_key with no policies in place can read and write every row, so write policies before you rely on RLS to keep data private. See supabase-js examples for both sign-in paths against this endpoint.

Keeping it in sync

If a table or column just created over base_run_sql, or over the direct/pooler connection, isn't showing up on the Data API yet, call base_reload_schema to refresh PostgREST's schema cache without waiting for it to notice on its own.

Next

supabase-js examples.