Tables
Créez le schéma de votre application depuis la console et interrogez-le immédiatement en HTTP : chaque table expose une API REST complète, filtrée par vos politiques de sécurité.
Créer une table
Deux modèles de départ, selon que les lignes appartiennent à un utilisateur ou sont gérées par votre backend :
- Avec colonne de propriétaire (recommandé) : chaque utilisateur lit et écrit ses propres lignes immédiatement.
- Minimale (identifiant + horodatage) : accessible avec la clé de service tant que vous n’avez pas écrit de politique.
Consulter et modifier les données
Le tableau parcourt le projet : colonnes, types, index, politiques par table, et un éditeur de lignes pour corriger une donnée sans écrire de SQL.
L’API REST des tables
Chaque table est exposée sous /rest/v1/. Envoyez la clé API du projet dans l’en-tête apikey ; joignez le jeton de session pour que les politiques s’appliquent au nom de l’utilisateur connecté.
curl
# $SESSION_JWT : le jeton de session de l'utilisateur connecté (fourni par le SDK au login)
# Lecture des 20 dernières lignes, au nom de l'utilisateur connecté
curl "https://<ref8>.kuunda-cloud.com/rest/v1/mes_taches?select=*&order=created_at.desc&limit=20" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer $SESSION_JWT"
# Écriture : la réponse renvoie la ligne enregistrée
curl -X POST "https://<ref8>.kuunda-cloud.com/rest/v1/mes_taches" \
-H "apikey: $ANON_KEY" \
-H "Authorization: Bearer $SESSION_JWT" \
-H "Content-Type: application/json" \
-d '{ "titre": "Première tâche" }'Sans jeton de session, la requête s’exécute en tant que visiteur anonyme : les politiques renvoient en général une liste vide.
Droits et disponibilité
Modifier le schéma, les données ou les politiques demande un rôle autorisé de l’organisation ; les autres rôles consultent en lecture seule. Les écrans de données nécessitent un projet actif : un projet en pause ou en cours de provisionnement n’est pas éditable.