Platform
API Keys & JWT
Anon and service_role keys, custom JWT expiry, and one-click secret rotation.
Every project ships with two API keys and a JWT signing secret. Use the anon key for client-side code, the service_role key for trusted servers, and rotate either at any time from Studio.
The anon key
A publishable key safe to embed in client code. It respects Row-Level Security policies, so users only see rows they're allowed to. Think of it as a gateway token — authorization decisions happen in your RLS policies.
// Safe in the browser
const client = createClient({
projectUrl: 'https://studio.orbitnest.io/api/projects/my-app',
anonKey: 'anon_eyJhbGciOiJIUzI1NiIs...',
});The service_role key
The master key. Bypasses RLS entirely — equivalent to a superuser database connection. Use it only on servers you control.
Never ship this to the client
// Server-side only
const adminClient = createClient({
projectUrl: 'https://studio.orbitnest.io/api/projects/my-app',
serviceRoleKey: process.env.ORBITNEST_SERVICE_ROLE_KEY,
});
// This ignores RLS and can see everything
const { data: allUsers } = await adminClient.from('users').select('*');JWT settings
Configure access-token and refresh-token expiry from API Keys → JWT Settings. Defaults:
access_tokenexpiry: 1 hourrefresh_tokenexpiry: 30 days- Signing algorithm: HS256
Shorter access tokens reduce blast-radius on leak; longer refresh tokens improve UX for long-running sessions. Pick what fits your threat model.
Rotating the JWT secret
Regenerating the JWT secret invalidates every existing session. Users will be signed out and must sign in again — the new secret immediately re-signs your anon and service_role keys so your infrastructure keeps working.
When to rotate
Using keys in requests
curl "https://studio.orbitnest.io/api/projects/my-app/database/tables/posts" \
-H "Authorization: Bearer ${ANON_KEY}"