Wire middleware sdk docs (`@supabase/middleware`)
https://github.com/supabase/middleware
Preview ref here:
https://docs-git-docs-supabase-middleware-sdk-supabase.vercel.app/docs/reference/middleware/introduction
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a Middleware SDK reference section to the documentation.
* Added installation guidance for npm, Yarn, pnpm, Deno, and Bun.
* Documented framework-agnostic middleware composition, typed shared
context, ordering, trust, and environment access across supported
runtimes.
* Added Middleware documentation to navigation and search.
* Identified the Middleware SDK as an alpha release.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Updates docs around scoped PAT's.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Clarified that temporary database access uses a Personal Access Token
as the Postgres role password.
* Updated API documentation to explain that Personal Access Tokens
support custom expiration rather than being described as long-lived.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
Brings the C# client reference in line with `supabase-csharp` 1.5. The
reference spec had drifted ~2 years and was missing most of the Auth,
MFA, Admin, and Storage surface.
## Changes
- **Fix example errors** in the v1 reference spec — corrected the
`From<T>()`/`Table<T>()` model example, `ListenType` realtime enum, a
mislabeled code fence, and other small mismatches.
- **Backfill release notes** from 1.0.1 through 1.5.0, reconstructed by
diffing the `Supabase.csproj` dependency pins across git tags and
pulling highlights from each sub-package changelog.
- **Document the undocumented API surface** (~27 new entries): Auth
(anonymous, ID token, SSO, refresh, link/unlink identity, code exchange,
reauthenticate, scoped sign-out), the full MFA API, the Admin API via
`AdminAuth`, and Storage (`Copy`, signed URLs, signed uploads).
- **Fix a latent bug**: the `ResetPasswordForEmail()` entry used a spec
id that matched no canonical section, so it never rendered. Renamed to
`reset-password-for-email`.
## Notes
- All signatures verified against the 1.5 SDK source.
- Entries render only when their spec id matches a slot in the shared
`common-client-libs-sections.json`; ids were mapped against that set.
- Spec YAML is Prettier-clean under the repo config.
Closes SDK-1369.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added C# release notes covering versions 1.0.1–1.5.0.
* Updated C# client documentation with current initialization patterns
and expanded authentication, session, identity, PKCE, MFA, Realtime,
Storage, and admin operation examples.
* Added Storage examples for file copying, signed URLs, signed uploads,
and uploads through signed URLs.
* Corrected code samples and clarified scoped sign-out and
password-reset guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Adds a docs guide, "Choosing a server-side package", that explains when
to use `supabase-js`, `@supabase/ssr`, or `@supabase/server` when
working with Supabase from JavaScript on the server. It includes a
decision table and a short code example for each, with one rule up
front: cookie-based sessions in SSR frameworks use `@supabase/ssr`,
per-request header auth in Edge Functions and other backend runtimes
uses `@supabase/server`, and `supabase-js` is the base client both wrap.
The guide is surfaced from the Auth overview page and the sidebar, and
is cross-linked from the `supabase-js` and `@supabase/server` reference
introductions so it is reachable from where developers start. It also
states that the packages coexist and are not replacements for each
other, and keeps combining `@supabase/server` with `@supabase/ssr` as an
advanced section.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added a guide explaining how to choose between Supabase server-side
JavaScript packages.
- Added the guide to Auth navigation and the getting-started content
listings.
- Added links to the new guidance throughout relevant JavaScript and
server documentation.
- **Documentation**
- Clarified when to use cookie-based sessions versus header-based
authentication.
- Added package comparisons, usage examples, advanced guidance, and
related next steps.
- Updated spelling support for framework names used in the
documentation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.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?
Docs update.
*
https://docs-git-docs-wire-server-v1-reference-supabase.vercel.app/docs/reference/server/introduction
*
<img width="417" height="628" alt="Screenshot 2026-07-06 at 6 13 33 PM"
src="https://github.com/user-attachments/assets/9fc27b04-038b-4434-8855-94051f898b5d"
/>
## What is the current behavior?
`@supabase/server` has no reference documentation page in the Supabase
docs. The library publishes a TypeDoc spec to GitHub Pages but the docs
pipeline was not wired up to consume it.
## What is the new behavior?
- Adds `spec/reference/server/v1/` with a `config.json` (category order:
Middleware, Primitives, Adapters, Errors, Types) and `partials/` for the
introduction and installing pages.
- Adds a `download.server.v1` Makefile target that fetches
`https://supabase.github.io/server/spec.json` into
`spec/reference/server/v1/server.json`, and wires it into the top-level
`download` target so it runs with the rest.
- Registers `server-v1` in `SUPPORTS_NEW_REFERENCE_PROCESS` so the build
pipeline picks up the new spec directory and generates
`content/reference/server/v1/` at build time.
- Seeds the generated `docs/ref/server/` partials (introduction and
installing) that the reference router serves.
## Additional context
The TypeDoc spec is produced by `@supabase/server`'s `docs.yml` workflow
on every push to `main`, so `make download.server.v1` will always pull
the latest published API surface. The companion PR in the server repo
([supabase/server#95](https://github.com/supabase/server/pull/95)) adds
the `@category` tags that the pipeline requires for symbols to appear in
navigation.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a new **Server SDK** item under **Reference**, linking to
`/reference/server` and marked with a **New** badge.
* Published **Server Reference v1** documentation for
`@supabase/server`, including **Introduction** and **Installing** pages.
* **Chores / Improvements**
* Enhanced the reference documentation generation to include Server v1
content.
* Improved reference detail handling (including clearer TypeDoc output
such as **Deprecated** notes).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
# Second try of making a new better process for SDK automation
Instead of building a new pipeline. We will take the lessons learned
form round 1, plus the good design and improvement on DX quality for
drop-in file as a single step required from SDK team and produce almost
identical set of files as used right now to render using the current
pipeline.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* New reference-content pipeline producing per-library reference
artifacts and integrating into prebuilds, search ingestion, and
rendering (type-aware examples).
* **Documentation**
* Added comprehensive JavaScript SDK v2 reference content and partials
(Auth MFA, passkeys, admin, TypeScript support, filters, modifiers,
Installing, Initializing, Buckets, etc.).
* **Tests & CI**
* Added regression snapshot test and updated workflows to refresh
reference snapshots and ensure spec downloads.
* **Chores**
* Updated ignore rules, build scripts, Makefile targets, and package
lifecycle hooks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Katerina Skroumpelou <mandarini@users.noreply.github.com>
Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>
## What kind of change does this PR introduce?
Docs update. Related to DEPR-551.
## What is the current behavior?
Docs MDX still uses the legacy `label` prop for Admonitions, even though
#45618 added `title` and kept `label` only as a backwards-compatible
alias after #45302 was reverted in #45535.
## What is the new behavior?
Migrates Docs-owned Admonitions from `label=` to `title=` without
changing rendered copy, component APIs, Studio callsites, design-system
examples, or the legacy `label` alias.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized admonition headings across the docs by switching how
admonition headings are provided (preserving all visible guidance and
examples). Content and instructions remain unchanged; this ensures
consistent rendering of callouts and improves uniformity across guides
and reference pages.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46053?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
Updates our documentation pages around the Data API to include
instructions on how to grant the necessary privileges across API roles
across tables and functions. Current behaviour means this is largely
unnecessary as privileges are granted by default on public schema, but
adding instructions will help cover scenarios where this isn't the case
and expose some of the underlying magic happening.
## To test:
- These updates refer to new settings that are added to the data api
that give more visibility and control over what tables and functions are
accessible via the api.
- To view these settings you'll need enable `tableEditorApiAccessToggle
` feature flag
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a new "Data API" guide and removed the old "Hardening the Data
API" page
* Updated navigation links to surface the new Data API guide
* Expanded quickstarts, SDK install pages, and security guides with
step‑by‑step Data API exposure, default‑privileges, RLS guidance, and
SQL GRANT examples (including function EXECUTE notes)
* Updated troubleshooting references and added redirects for legacy
documentation paths
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: SaxonF <1072756+SaxonF@users.noreply.github.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: Chris Chinchilla <chris@chrischinchilla.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?
Updates verbiage throughout docs to use postgres over postgresql.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated terminology throughout documentation, guides, and resources
for consistent product naming across all user-facing materials,
including page titles, descriptions, and reference documentation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR fixes some prettier issues:
- Bump and unify all prettier versions to 3.7.3 across teh whole repo
- Bump the SQL prettier plugin
- When running `test:prettier`, check `mdx` files also
- Run the new prettier format on all files
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## What kind of change does this PR introduce?
Documentation and copy corrections.
## What is the current behavior?
Several docs and one Studio file contain grammar, spelling, and
capitalization issues:
- JS v1 upgrade guide: "we'll continuing" (should be "we'll continue"),
"Some the [PR]" (should be "See the [PR]"), extra space before comma
- Realtime docs: "PostgresSQL" (should be "PostgreSQL") in 2 files
- Kotlin SDK installing docs: "Websockets" (should be "WebSockets"),
"Checkout the" (should be "Check out the")
- Broadcast guide: "Websockets" (should be "WebSockets") in code
comments (5 occurrences)
- Prisma troubleshooting: "Checkout this" (should be "Check out this")
- Edge function template: "Websocket Server Example" (should be
"WebSocket Server Example")
## What is the new behavior?
All grammar, spelling, and capitalization issues are corrected:
- **Grammar**: "we'll continue" (verb tense), "See the [PR]" (correct
word), removed extra space
- **Spelling**: "PostgreSQL" (correct product name)
- **Capitalization**: "WebSocket" / "WebSockets" follows the official
W3C/IETF naming convention
- **Word splitting**: "Check out" as a phrasal verb (two words), vs
"checkout" the noun
## Files changed (8)
- `apps/docs/docs/ref/javascript/v1/upgrade-guide.mdx` — grammar fixes
(3 issues)
- `apps/docs/docs/ref/self-hosting-realtime/introduction.mdx` —
PostgresSQL -> PostgreSQL
- `apps/docs/docs/ref/realtime/realtime.mdx` — PostgresSQL -> PostgreSQL
- `apps/docs/docs/ref/kotlin/v2/installing.mdx` — WebSockets + Check out
- `apps/docs/docs/ref/kotlin/installing.mdx` — WebSockets + Check out (2
occurrences)
- `apps/docs/content/guides/realtime/broadcast.mdx` — Websockets ->
WebSockets (5 occurrences)
- `apps/docs/content/troubleshooting/prisma-error-management-Cm5P_o.mdx`
— Check out
- `apps/studio/components/interfaces/Functions/Functions.templates.ts` —
WebSocket template name
## What kind of change does this PR introduce?
Documentation / text fix (grammar)
## What is the current behavior?
Several places in the codebase use "a" before acronyms that start with
vowel sounds, which is grammatically incorrect:
- "enter a MFA code" (MFA is pronounced "em-eff-ay", starting with a
vowel sound)
- "a SMS with a OTP" (SMS = "ess-em-ess", OTP = "oh-tee-pee")
## What is the new behavior?
Corrected to use "an" before acronyms with vowel sounds:
- "enter an MFA code"
- "an SMS with an OTP"
## Files changed
- `apps/studio/data/profile/mfa-challenge-and-verify-mutation.ts` -
comment fix
- `apps/docs/content/guides/platform/multi-factor-authentication.mdx` -
user-facing docs
- `apps/docs/docs/ref/javascript/v1/upgrade-guide.mdx` - code comment in
example
- `apps/docs/docs/ref/dart/v0/upgrade-guide.mdx` - code comment in
example
## Additional context
The rule: use "an" before acronyms pronounced with an initial vowel
sound, regardless of the first letter. "MFA" starts with "em" (vowel
sound), "SMS" starts with "ess" (vowel sound), "OTP" starts with "oh"
(vowel sound).
Partials are currently defined via MDX includes. This PR switches to pre-compile-time partials, which have a new syntax:
```
<$Partial path="path/to/file.mdx" />
```
## Rationale
This produces two improvements:
1. Partial substitution can occur in pipelines that don't use MDX compilation. For example, we can now do partial substitution before building the search index, so partial content will also be indexed.
2. After the App Router migration, the MDXProviders should've been deprecated, but were kept around for the sole reason of making partials work, and leading to us shipping unnecessary client-side code. We get a minor decrease in overall client bundle size (5.74 MB to 5.6 MB) by getting rid of the Providers.
## Breaking changes
Besides the change to partial syntax, the arguments are also less powerful than before because we are doing string substitution and don't have the full power of JS. Defining string variables is still possible (documented in the Contributing guide), and since that's all we actually do in practice, this shouldn't be too cumbersome. There is always the escape hatch of making a custom component for more complex content reuse cases.
Migrates client SDK References to App Router. (Management and CLI API references aren't migrated yet, nor are self-hosting config references.)
Some notes:
Big changes to the way crawler pages are built and individual section URLs (e.g., javascript/select) are served. All of these used to be SSG-generated pages, but the number of heavy pages was just too much to handle -- slow as molasses and my laptop sounded like it was taking off, and CI sometimes refuses to build it all at all.
Tried various tricks with caching and pre-generating data but no dice.
So I changed to only building one copy of each SDK+version page, then serving the sub-URLs through a response rewrite. That's for the actual user-visible pages.
For the bot pages, each sub-URL needs to be its own page, but prebuilding it doesn't work, and rendering on demand from React components is too slow (looking for super-fast response here for SEO). Instead I changed to using an API route that serves very minimal, hand-crafted HTML. It looks ugly, but it's purely for the search bots.
You can test what bots see by running curl --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" <URL_OF_PAGE>
Also added some smoke tests to run against prod for the crawler routes, since we don't keep an eye on those regularly, and Vercel config changes could surprise-break them. Tested the meta images on Open Graph and all seems to work fine.
With this approach, full production builds are really fast: ~5 minutes
Starts using the new type spec handling, which is better at finding params automatically, so I could remove some of the manually written ones from the spec files.
* exclude dart, python, and swift from error codes menu
* Update the error code doc to be client lib agnostic
* run formatter
* Add a filter to filter out section items
* Update apps/docs/components/Navigation/NavigationMenu/NavigationMenuRefList.tsx
* docs: move error codes table in a separate component
* Add auth error codes section for kotlin
Fix missing typo in the api introduction document
Changes text from `Authorization Bearer <supabase_personal_token` to `Authorization Bearer <supabase_personal_token>`
* Refresh of c# client docs to reflect Supabase@v1.0.0 and new Nuget Package Names
* Clarify maintainers and contributors
* Separate C# v0 and v1 references
* Format
---------
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
Katerina Skroumpelou
