Files
supabase/apps/docs/content/guides/api/using-custom-schemas.mdx
Danny White 24be387cdb docs: use sign in terminology across guides and style guides (#49877)
## What kind of change does this PR introduce?

Docs update. Aligns documentation and style guides with the **Sign in /
Sign out / Sign up** platform standard.

Closes DOCS-1328. Related to
[#49874](https://github.com/supabase/supabase/pull/49874).

## What is the current behavior?

Docs style guides prefer _login_ / _log in_. Guide prose uses mixed
login and sign in wording.

## What is the new behavior?

- [WORD_LIST.md](apps/docs/WORD_LIST.md) and
[copywriting.mdx](apps/design-system/content/docs/copywriting.mdx)
document the sign in standard
- Design-system auth examples updated
- Guide prose and API reference spec descriptions updated

### Terminology

**Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use
_sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match
Studio UI labels (**Sign in**, **Sign out**, **Sign up**).

**Preserved intentionally:**

| Category | Keep as-is | Example |
| -------- | ---------- | ------- |
| Feature name | social login | `/social-login`, `features.mdx` heading,
OAuth provider section |
| URL slugs | `login` in paths | `/phone-login`, `/login-flows`,
`choosing-login-flow` |
| CLI | `supabase login` / `supabase logout` | Reference ids
`supabase-login` / `supabase-logout`; executable commands unchanged |
| SDK methods | `logout()` | Kotlin/Swift method names in API reference
titles and examples |
| Third-party UI | Provider product labels | Facebook Login, Kakao
Login, portal **Login** buttons |
| Postgres | Database terminology | login privileges, login credentials,
login via role |
| Audit/logging | Log prose | "Generates the following **log** in the
Postgres Logs" |
| Code and routes | Paths and filenames | `app/login/`, `Login.tsx`,
`demos/android-login` |
| External URLs | Third-party login pages | `dash.cloudflare.com/login`,
`console.neon.tech/login`, `vercel.com/login` |
| API identifiers | Event and field names | Audit actions
`login`/`logout`, `should_logout_user` |

## To test

- Run `pnpm lint:mdx` in `apps/docs`
- Spot-check `features.mdx`, `social-login.mdx`, and a provider guide
(e.g. Facebook, Kakao)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Standardized authentication terminology across guides, reference
material, CLI documentation, and copywriting guidance using “sign in,”
“sign out,” and “sign up.”
* Updated authentication instructions, headings, link text, examples,
and SSO guidance for clearer, more consistent wording.
* Corrected related grammar, spelling, hyphenation, and documentation
links while preserving established product names and implementation
commands.
* **Style**
  * Refined code examples with consistent import ordering and spacing.
* **Examples**
* Updated authentication button and menu labels to “Sign in” and “Sign
out.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-04 09:10:25 +10:00

127 lines
4.0 KiB
Plaintext

---
id: 'using-custom-schemas'
title: 'Using Custom Schemas'
description: 'You need additional steps to use custom database schemas with data APIs.'
---
By default, your database has a `public` schema which is automatically exposed on data APIs.
## Creating custom schemas
You can create your own custom schema/s by running the following SQL, substituting `myschema` with the name you want to use for your schema:
```sql
CREATE SCHEMA myschema;
```
## Exposing custom schemas
You can expose custom database schemas - to do so you need to follow these steps:
1. Go to [API settings](/dashboard/project/_/settings/api) and add your custom schema to "Exposed schemas".
2. Run the following SQL, substituting `myschema` with your schema name:
```sql
GRANT USAGE ON SCHEMA myschema TO anon, authenticated, service_role;
GRANT ALL ON ALL TABLES IN SCHEMA myschema TO anon, authenticated, service_role;
GRANT ALL ON ALL ROUTINES IN SCHEMA myschema TO anon, authenticated, service_role;
GRANT ALL ON ALL SEQUENCES IN SCHEMA myschema TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON TABLES TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON ROUTINES TO anon, authenticated, service_role;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA myschema GRANT ALL ON SEQUENCES TO anon, authenticated, service_role;
```
Now you can access these schemas from data APIs:
<Tabs
scrollable
size="small"
type="underlined"
defaultActiveId="javascript"
queryGroup="language"
>
<TabPanel id="javascript" label="JavaScript">
```js
// Initialize the JS client
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, {
db: { schema: 'myschema' },
})
// Make a request
const { data: todos, error } = await supabase.from('todos').select('*')
// You can also change the target schema on a per-query basis
const { data: todos, error } = await supabase.schema('myschema').from('todos').select('*')
```
<Admonition type="note">
With generated `Database` types that include `public`, `createClient<Database>(...)` type-checks `db.schema` against `public` only, unless the schema name is also passed as the second generic: `createClient<Database, 'myschema'>(...)`. `supabase.schema('myschema').from(...)` infers its schema per call and needs no second generic. In both cases `myschema` has to be present in the generated `Database` type.
</Admonition>
</TabPanel>
<$Show if="sdk:dart">
<TabPanel id="dart" label="Dart">
```dart
// Initialize the Flutter client
await Supabase.initialize(
url: supabaseUrl,
publishableKey: publishableKey,
postgrestOptions: const PostgrestClientOptions(schema: 'myschema'),
);
final supabase = Supabase.instance.client;
// Make a request
final data = await supabase.from('todos').select();
// You can also change the target schema on a per-query basis
final data = await supabase.schema('myschema').from('todos').select();
````
</TabPanel>
</$Show>
<$Show if="sdk:csharp">
<TabPanel id="csharp" label="C#">
```c#
// Initialize the client with a custom schema
var supabase = new Supabase.Client(
SUPABASE_URL,
SUPABASE_PUBLISHABLE_KEY,
new SupabaseOptions { Schema = "myschema" }
);
await supabase.InitializeAsync();
// Make a request
var todos = await supabase.From<Todo>().Get();
```
</TabPanel>
</$Show>
<TabPanel id="curl" label="cURL">
```bash
# Append /rest/v1/ to your URL, and then use the table name as the route.
# for GET or HEAD request use Accept-Profile
curl '<SUPABASE_URL>/rest/v1/todos' \
-H "apikey: <SUPABASE_PUBLISHABLE_KEY>" \
-H "Authorization: Bearer <SUPABASE_PUBLISHABLE_KEY>" \
-H "Accept-Profile: myschema"
# for POST, PATCH, PUT and DELETE Request use Content-Profile
curl -X POST '<SUPABASE_URL>/rest/v1/todos' \
-H "apikey: <SUPABASE_PUBLISHABLE_KEY>" \
-H "Authorization: Bearer <SUPABASE_PUBLISHABLE_KEY>" \
-H "Content-Type: application/json" \
-H "Content-Profile: myschema" \
-d '{"column_name": "value"}'
````
</TabPanel>
</Tabs>