- extends/supersedes: #46665
- towards COM-269
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Standardized Edge Function entrypoints across examples to a consistent
`export default` shape, with runtime-provided admin access for
storage/database operations.
* Updated public endpoint handling to use appropriate auth modes.
* **Bug Fixes**
* Improved error handling to return structured JSON responses with
correct HTTP status codes for invalid requests and failures.
* Harmonized local invocation examples to use the right header format.
* **Chores**
* Updated example `verify_jwt` settings to disable JWT verification for
public/demo endpoints.
* **Documentation**
* Fixed README typo and refreshed invocation curl examples.
* **Tests**
* None.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Tomas Pozo <tomaspozogarzon@gmail.com>
## Problem
Edge Function examples that use the new publishable/secret API keys read
them with a double lookup:
```ts
const SUPABASE_SECRET_KEYS = JSON.parse(Deno.env.get('SUPABASE_SECRET_KEYS')!)
const secretKey = Deno.env.get(SUPABASE_SECRET_KEYS['default']) // ❌ returns undefined
```
`SUPABASE_SECRET_KEYS` / `SUPABASE_PUBLISHABLE_KEYS` are a JSON object
that maps a key name to the **actual key value** (e.g.
`{"default":"sb_secret_..."}`), confirmed by:
- the self-hosted injection in `docker/docker-compose.yml`
(`SUPABASE_SECRET_KEYS: "{\"default\":\"${SUPABASE_SECRET_KEY:-}\"}"`)
- the `@supabase/server` SDK README
So `SUPABASE_SECRET_KEYS['default']` is already the key. Wrapping it in
another `Deno.env.get(...)` looks up an env var named `sb_secret_...`,
which doesn't exist, so the value is `undefined` and the examples fail
at runtime.
## Fix
Unwrap the outer `Deno.env.get(...)` so the key is read directly:
```ts
const SUPABASE_SECRET_KEYS = JSON.parse(Deno.env.get('SUPABASE_SECRET_KEYS')!)
const secretKey = SUPABASE_SECRET_KEYS['default'] // ✅
```
Applied across 23 files (example functions, the
`examples/prompts/edge-functions.md` codegen guidance, and two docs
guides). The correct `JSON.parse(Deno.env.get('SUPABASE_SECRET_KEYS')!)`
declaration line is untouched. The generated `apps/docs/examples/` copy
regenerates from `examples/` at build time.
## Notes
- Docs context:
[#46600](https://github.com/supabase/supabase/pull/46600), which
documents the same key model.
- Follow-up (not in this PR): a few examples send the secret key on the
`Authorization: Bearer` header, which the new keys reject. Worth a
separate audit.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Clarified examples and guides for correctly reading parsed Supabase
secret and publishable key maps.
* **Examples**
* Standardized credential usage across Edge Functions and samples so
Supabase clients consistently receive keys from the parsed key maps
rather than indirect lookups.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated examples and guides to use Supabase publishable (client) keys
instead of anon keys for client-side usage across frameworks and
platforms.
* Renamed environment variable examples and .env templates to reflect
publishable key naming.
* Adjusted sample requests and client-init examples to send/use the
publishable key via the apikey header where applicable.
* Updated references from service_role to secret for server-side
credential guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: fadymak <fady@fadymak.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Replaces "stored procedures" with "functions" for everything related to
the Data API.
## Additional context
It's not accurate to call database functions "stored procedures". It may
have been that way before Postgres 11, but now it causes confusion
because PostgREST allows functions and not stored procedures.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized terminology across docs, SDK guides, CLI/config specs,
examples, UI, and config comments to use "database functions" instead of
"stored procedures".
* Updated API docs, CLI/config descriptions, Studio UI labels, help
text, empty-state and navigation copy, RPC documentation, and example
text for consistency.
* Adjusted explanatory text and error/help messages to reflect the
revised terminology.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
