Tables
Design your application schema from the console and query it immediately over HTTP: every table exposes a full REST API, filtered by your security policies.
Create a table
Two starting models, depending on whether rows belong to a user or are managed by your backend:
- With an ownership column (recommended): each user reads and writes their own rows straight away.
- Minimal (identifier + timestamp): reachable with the service key until you write a policy.
Browse and edit data
The table view walks through the project: columns, types, indexes, per-table policies, plus a row editor to fix a value without writing SQL.
The table REST API
Every table is exposed under /rest/v1/. Send the project API key in the apikey header; add the session token so policies apply on behalf of the signed-in user.
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" }'Without a session token, the request runs as an anonymous visitor: policies usually return an empty list.
Permissions and availability
Changing the schema, the data or the policies requires an authorised organisation role; other roles get read-only access. Data screens require an active project: a paused or still-provisioning project cannot be edited.