Feature request: let Postgres call its own Edge Functions on every branch, with no hand-copied URLs or keys

[icopp]

Supabase's own guides for calling an Edge Function from Postgres (Scheduling Edge Functions, Automatic embeddings) all follow one pattern: pg_cron → pg_net → the project URL and a key read from Vault. Every step of that pattern assumes one hand-configured project. With Branching, it breaks down.

1. Postgres cannot learn its own API URL

• An Edge Function gets SUPABASE_URL automatically. Postgres gets nothing, so every guide has you paste https://<project-ref>.supabase.co into vault.create_secret(...) by hand (discussion #12813 has asked about this for years).
• A preview branch gets a new project ref at creation time, so no value in config.toml or a dotenvx file can name it ahead of time. [remotes.<branch>.db.vault] covers persistent branches only.
• Locally, the URL that works from inside Postgres is http://api.supabase.internal:8000, a host the CLI hard-codes and the docs mention only in passing. It differs from the SUPABASE_URL the local functions see.
• The workarounds people use are a CI step that calls the Management API after branch creation (which must be created and maintained separately by each Supabase customer), or skipping preview branches entirely.

2. Branching cannot manage a named secret key

• The new API keys allow scoped, named secret keys, and @supabase/server's withSupabase({ auth: 'secret:<name>' }) checks for one. That is the right auth for a cron-to-function call.
• But config.toml cannot declare a named key, so a branch never gets one. Each key has to be created in the dashboard for each project, then copied into env files and Vault by hand. That does not scale past one or two persistent branches.

3. Getting a key into Vault means copying it in plaintext

• A key reaches Vault only by pasting its value into SQL, or through [db.vault] with env() from an env file someone filled in by hand. There is no way to give Postgres a key the platform already knows.
• The docs examples show the anon or service key as a literal in the cron SQL, or in a vault.create_secret('<your key>', ...) someone pastes by hand. Followed literally, they put a long-lived key into migration history or the SQL editor log.
• The older standard_webhook_* pattern is gone, and nothing with the same zero-config property has replaced it.

What we did instead

A migration generates a random token into Vault, the cron job sends it in a header, and the function reads the same Vault entry back with service-role access and compares the two in constant time. That works on every branch with nothing configured, but every project that wants this pattern has to rebuild it from scratch.

Ask

1. A built-in way for Postgres to read its own API URL on every branch and locally, e.g. a supabase.api_url setting or function.
2. Named secret keys declared in config.toml, created per branch and with unique values per branch, and readable from Vault without the value ever appearing in a file.
3. A first-party way to call your own Edge Function from SQL, authenticated, e.g. net.invoke_function('name', body) or a Vault entry the platform maintains. Then update the guides to use it instead of pasted URLs and keys.