Clés API
Trois clés donnent accès à votre projet, chacune pour un usage précis. Les confondre — ou exposer la mauvaise — est la première cause d’incident de sécurité sur une plateforme comme la nôtre.
Clé anonyme
Destinée au navigateur, à l’application mobile et à tout code public. Elle identifie votre projet sans donner de droits : chaque requête reste filtrée par vos politiques, ligne par ligne.
Clé anonyme sandbox
Même principe, mais elle ne touche que le sandbox. Combinez-la avec l’en-tête X-Kuunda-Env: sandbox pour que vos tests et vos agents écrivent ailleurs que dans les données réelles.
Clé service_role
Elle contourne les politiques : réservez-la au serveur — CI, outillage, tâche d’administration — et ne la livrez jamais dans un navigateur, une application mobile ou un dépôt public.
- Une clé exposée se remplace depuis la console : traitez la rotation comme une opération de routine, pas comme un incident.
- Pour une application cliente, la clé anonyme et une session utilisateur connectée suffisent à écrire au nom de cet utilisateur.
- Les migrations et l’automatisation serveur passent par la clé service_role ; les agents utilisent un jeton dédié, révocable indépendamment.
Vérifier une configuration
L’assistant de connexion diagnostique votre projet : API REST opérationnelle, isolation des données appliquée, rôle utilisé par les appels, et l’URL à copier dans votre client. C’est le premier écran à ouvrir quand une intégration ne répond pas.
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!);La clé service_role se lit dans une variable d’environnement côté serveur, jamais dans un fichier livré au navigateur.