API keys
Three keys reach your project, each for one specific use. Confusing them — or exposing the wrong one — is the leading cause of security incidents on a platform like ours.
Anonymous key
Meant for the browser, the mobile app and any public code. It identifies your project without granting rights: every request stays filtered by your policies, row by row.
Sandbox anonymous key
Same principle, but it only reaches the sandbox. Combine it with the X-Kuunda-Env: sandbox header so your tests and agents write somewhere other than real data.
service_role key
It bypasses policies: keep it server-side — CI, tooling, an administrative job — and never ship it in a browser, a mobile app or a public repository.
- An exposed key is replaced from the console: treat rotation as routine, not as an incident.
- For a client application, the anonymous key plus a signed-in user session are enough to write on that user’s behalf.
- Migrations and server automation use the service_role key; agents use a dedicated token, revocable on its own.
Check a configuration
The connection wizard diagnoses your project: REST API operational, data isolation applied, the role used by requests, and the URL to copy into your client. It is the first screen to open when an integration stops answering.
JavaScript
import { createClient } from '@kuunda/kuunda-js';
// Navigateur, application mobile, code public : clé anonyme + session utilisateur.
const kuunda = createClient(process.env.NEXT_PUBLIC_KUUNDA_URL!, process.env.NEXT_PUBLIC_KUUNDA_ANON_KEY!);
// Serveur uniquement (CI, outillage, tâche d'administration) : clé service_role.
const admin = createClient(process.env.KUUNDA_URL!, process.env.KUUNDA_SERVICE_ROLE_KEY!);The service_role key is read from a server-side environment variable, never from a file shipped to the browser.