## Summary
Cross-referenced recent commits across all 6 SDK repos (supabase-js,
supabase-flutter, supabase-py, supabase-swift, supabase-kt,
supabase-csharp) against `apps/docs/spec/` and
`apps/docs/content/guides/`. Most recent commits were
CI/chore/release/patch-fix noise; the following genuine feature gaps
were found and fixed.
## Changes analyzed
- **supabase-swift**: `dryRun()`, `notIn()`, `maybeSingle()` (PR
supabase/supabase-swift#1114) and `signInWithWeb3()` (PR
supabase/supabase-swift#1138)
- **supabase-kt**: `dryRun()`, `notIn()`, `maybeSingle()` (PR
supabase-community/supabase-kt#1365)
## Documentation updates
- `apps/docs/spec/supabase_swift_v2.yml` — added `notin`, `dry-run`,
`maybe-single` filter/modifier entries and a `sign-in-with-web3` auth
entry (Web3/Ethereum/Solana sign-in was already documented for JS and
Dart, missing for Swift)
- `apps/docs/spec/supabase_kt_v3.yml` — added `notin`, `maybe-single`,
`dry-run` entries
- `apps/docs/spec/common-client-libs-sections.json` — registered nav
entries for the two brand-new cross-SDK ids (`notin`, `dry-run`);
`sign-in-with-web3` was already registered
## Explicitly out of scope
- **Kotlin `custom_claims_allowlist`** (added to
`CustomOAuthProvider`/`CustomProviderBuilder` in supabase-kt) — skipped.
The Kotlin spec has no admin custom-OAuth-provider section documented at
all yet (create/list/get/update/delete), so adding just this one field
would require authoring a whole new, currently-undocumented admin API
section from scratch — too large/risky to guess correctly in this pass.
Flagging for a follow-up.
- Dart's recently-shipped storage features (vector buckets,
analytics/Iceberg buckets, `purgeCache`, `downloadStream`,
`listPaginated`) were checked and are already fully documented in
`supabase_dart_v2.yml`.
- Swift/Kotlin lacking Storage vector-bucket/analytics-bucket docs — out
of scope, those SDKs didn't ship that feature in this commit range
(Dart-only so far).
## Test plan
- [x] `python3 -c "import yaml; yaml.safe_load(open(...))"` — both
edited YAML specs parse cleanly
- [x] `python3 -c "import json; json.load(open(...))"` — nav JSON parses
cleanly
- [ ] Visual check of the rendered reference pages for
`notIn`/`dryRun`/`maybeSingle`/`signInWithWeb3` on Swift and Kotlin
reference docs
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added documentation for `notIn()` query filtering across supported
Kotlin and Swift query operations.
* Documented `maybeSingle()` for safely handling zero-or-one query
results without raising a single-row error.
* Added guidance for `dryRun()` mutations, including rollback behavior
and returned results.
* Added Swift authentication documentation for Web3 sign-in with
Ethereum and Solana credentials.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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
* 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>
