API REST

Vue d’ensemble

Rebase génère automatiquement une API complète à partir des définitions de vos collections :

• API REST — Points de terminaison CRUD pour chaque collection sur /api/data/:slug
• Spécification OpenAPI — Spécification lisible par machine sur /api/docs
• Swagger UI — Explorateur d’API interactif sur /api/swagger (mode dev uniquement)

Aucun code n’est requis — définissez vos collections et l’API apparaît automatiquement.

Points de terminaison REST

Pour chaque collection, les points de terminaison suivants sont générés. Toutes les autres routes montées par le backend — auth, stockage, admin, méta — se trouvent dans l’index des points de terminaison.

Méthode	Chemin	Description
GET	/api/data/:slug	Lister les entités
GET	/api/data/:slug/count	Compter les entités
GET	/api/data/:slug/aggregate	count(), sum(), avg(), min(), max(), optionnellement groupés. Accepte les mêmes filtres que le point de terminaison de liste, et le RLS s’applique aux lignes agrégées — voir Requêtage
GET	/api/data/:slug/:id	Obtenir une seule entité
POST	/api/data/:slug	Créer un enregistrement
PATCH	/api/data/:slug/:id	Mettre à jour un enregistrement (partiel — seules les propriétés envoyées sont écrites)
DELETE	/api/data/:slug/:id	Supprimer un enregistrement
POST	/api/data/:slug/bulk	Créer plusieurs entités en une seule transaction
PATCH	/api/data/:slug/bulk	Mettre à jour plusieurs entités en une seule transaction
POST	/api/data/:slug/bulk/delete	Supprimer plusieurs entités en une seule transaction
POST	/api/data/_batch	Écrire à travers plusieurs collections en une seule transaction

Routes de sous-collections

Les relations imbriquées sont accessibles via les chemins d’URL :

GET    /api/data/authors/42/posts         → list author's posts
GET    /api/data/authors/42/posts/7       → get a specific post by author
POST   /api/data/authors/42/posts         → create a post for author
PATCH  /api/data/authors/42/posts/7       → update the post
DELETE /api/data/authors/42/posts/7       → delete the post

Mécanique de routage et analyse des segments

Pour gérer des profondeurs arbitraires de sous-collections imbriquées, Rebase route les requêtes entrantes à l’aide de la regex du paramètre :rest{.+} de Hono. Le moteur interne d’analyse des segments analyse les chemins en comptant les segments séparés par des barres obliques :

• Nombre impair de segments (ex. authors/42/posts -> 3 segments) représente une requête de liste de collection.
• Nombre pair de segments (ex. authors/42/posts/7 -> 4 segments) représente une opération sur un identifiant d’entité spécifique. Le dernier segment est extrait en tant qu’entityId cible.

Le moteur filtre les espaces de noms système réservés (ex. history) de l’analyse des segments de chemin pour éviter les collisions avec les points de terminaison intégrés.

Authentification

Tous les points de terminaison de données requièrent une authentification par défaut. Incluez un jeton Bearer dans l’en-tête Authorization :

curl -H "Authorization: Bearer <access-token>" \
     https://api.example.com/api/data/products

Pour les appels de serveur à serveur, utilisez la clé de service :

curl -H "Authorization: Bearer <service-key>" \
     https://api.example.com/api/data/products

Filtrage

Utilisez des paramètres de requête de style PostgREST pour filtrer les résultats. Le format est ?field=operator.value :

# Exact match
GET /api/data/products?active=eq.true

# Comparison operators
GET /api/data/products?price=gt.100
GET /api/data/products?price=lte.50

# Multiple filters (AND)
GET /api/data/products?active=eq.true&price=gt.10

# IN operator — match any value in a set
GET /api/data/products?status=in.(draft,published)

# NOT IN
GET /api/data/products?status=nin.(archived,deleted)

# Array contains
GET /api/data/products?tags=cs.electronics

# Array contains any
GET /api/data/products?tags=csa.(electronics,books)

Opérateurs de filtrage

Opérateur	Signification	Exemple
eq	Égal à (==)	?active=eq.true
neq	Non égal à (!=)	?status=neq.draft
gt	Supérieur à (>)	?price=gt.100
gte	Supérieur ou égal à (>=)	?price=gte.100
lt	Inférieur à (<)	?price=lt.50
lte	Inférieur ou égal à (<=)	?price=lte.50
in	Présent dans le tableau	?status=in.(a,b,c)
nin	Absent du tableau	?status=nin.(a,b)
cs	Le tableau contient	?tags=cs.value
csa	Le tableau contient l’un des éléments	?tags=csa.(a,b)
like	Correspondance de motif, sensible à la casse (like)	?sku=like.AB-%
ilike	Correspondance de motif, insensible à la casse (ilike)	?name=ilike.%widget%
nlike	Ne correspond pas au motif (not-like)	?sku=nlike.TMP-%
nilike	Ne correspond pas au motif, insensible à la casse (not-ilike)	?name=nilike.%test%
isnull	La colonne est NULL (is-null)	?deleted_at=isnull.null
notnull	La colonne n’est pas NULL (is-not-null)	?deleted_at=notnull.null

isnull et notnull ignorent leur valeur — l’opérateur constitue toute la condition, et tout ce qui suit le point est ignoré. Le SDK écrit .null, c’est donc la syntaxe que vous verrez passer sur le réseau.

eq.null est la chaîne de quatre caractères, pas IS NULL

?deleted_at=eq.null recherche le texte littéral null. En SQL, = NULL n’est jamais vrai, il n’existe donc aucune interprétation d’eq.null qui puisse correspondre au test de nullité — utilisez isnull pour cela. C’est exactement pour cette raison que le SDK sérialise .where("deleted_at", "==", null) sous la forme isnull.null.

Opérateurs logiques

Utilisez or, and et not pour les conditions complexes :

# OR: match products that are either cheap or on sale
GET /api/data/products?or=(price.lt.10,on_sale.eq.true)

# AND: explicit conjunction
GET /api/data/products?and=(active.eq.true,price.gt.0)

# NOT: everything that is not a discontinued in-stock item
GET /api/data/products?not=(discontinued.eq.true,stock.gt.0)

not inverse la conjonction de ses conditions : not(a) équivaut à NOT a, et not(a,b) à NOT (a AND b). Il compile vers un véritable NOT (...) SQL plutôt que vers des opérateurs inversés — la logique SQL étant trivaluée, NOT (a AND b) et (NOT a) OR (NOT b) cessent de concorder dès qu’un NULL entre en jeu. Une négation inclut donc les lignes dont la colonne est NULL, ce qui correspond au comportement de NOT ; ajoutez un notnull avec un AND si ce n’est pas ce que vous souhaitez.

Un seul groupe par requête : or l’emporte sur and, et les deux sur not. Il s’agit de trois manières d’écrire le même emplacement, pas de trois filtres distincts. Imbriquez-les plutôt :

GET /api/data/products?or=(price.lt.10,and(active.eq.true,price.gt.0))
GET /api/data/products?not=(or(status.eq.draft,status.eq.archived))

Les groupes peuvent être imbriqués jusqu’à 32 niveaux de profondeur ; au-delà, la requête est rejetée avec INVALID_LOGICAL_GROUP.

Un groupe vient restreindre les filtres de champ plutôt que de les remplacer — voir Comment les filtres se combinent.

Le dialecte JSON where

Les filtres de champ ci-dessus sont l’une des deux manières d’envoyer un filtre. L’autre consiste à utiliser un objet JSON unique, ce que le document OpenAPI publie sur chaque GET /api/data/{slug} et ce qu’acceptent les routes de sous-collections imbriquées :

GET /api/data/products?where={"status":["==","active"],"price":[">=",100]}

Chaque clé est un champ, chaque valeur est un tuple canonique [opérateur, valeur] — les mêmes tuples que le SDK produit. Une valeur peut également être une chaîne avec point pré-sérialisée ({"status":"eq.active"}) ou un scalaire brut ({"status":"active"}) ; tous les trois compilent vers la même condition.

La différence notable : le JSON transporte les types. ?price=gte.100 envoie la chaîne "100" et le pilote la convertit selon le type de la colonne, tandis que ?where={"price":[">=",100]} envoie un nombre. Pour une colonne dont les interprétations textuelles et numériques diffèrent — une chaîne de version, un code préfixé de zéros — c’est le paramètre à privilégier.

Un where malformé renvoie une erreur 400 INVALID_WHERE, plutôt qu’un filtre ignoré en silence : l’ignorer exécuterait la lecture sans filtre et retournerait tout ce que la sécurité au niveau des lignes (RLS) autorise.

Comment les filtres se combinent

?field=op.value, ?where=, ?or=/?and= et ?searchString= sont indépendants, et chacun d’eux présent doit correspondre :

(field filters and `where`, AND-ed together)
  AND (the logical group)
  AND (the search string)

Il n’y a aucun moyen de combiner l’un avec l’autre via un OU (OR). Tout ce qui n’est pas un simple ET (AND) de ces groupes doit se trouver à l’intérieur d’un seul arbre or=/and=.

Tri

Utilisez orderBy avec le format field:direction :

# Sort by price descending
GET /api/data/products?orderBy=price:desc

# Sort by name ascending (default)
GET /api/data/products?orderBy=name:asc

Une direction manquante vaut asc. Une direction qui n’est ni asc ni desc, ou un champ qui n’existe pas dans la collection, renvoie une erreur 400 — et non un 200 avec les lignes dans l’ordre choisi arbitrairement par la base de données, ce qui serait impossible à distinguer d’un tri réussi.

Plusieurs clés

La notation abrégée accepte une seule clé. Pour en spécifier plusieurs, passez un tableau JSON — la seconde clé départage les lignes jugées égales par la première :

# By category, and newest first within each category
GET /api/data/products?orderBy=[{"field":"category"},{"field":"createdAt","direction":"desc"}]

Les deux syntaxes sont valables sur toutes les routes listant des lignes, y compris les routes imbriquées (/api/data/authors/:id/posts). Chaque tri se termine par l’identifiant de la ligne par ordre décroissant, que vous l’ayez demandé ou non : c’est ce qui rend l’ordonnancement total, car paginer sur un ordre qui n’est pas total répète et saute des lignes.

Un paramètre ?orderBy= répété ne constitue pas un tri à plusieurs clés — le dernier l’emporte, comme pour tout autre paramètre de requête. Utilisez le tableau.

Positionnement des valeurs NULL lors du tri

Par défaut, les valeurs NULL sont triées en dernier par ordre croissant et en premier par ordre décroissant, ce qui correspond à la convention de Postgres. Un troisième segment séparé par deux-points permet d’en décider autrement :

# Newest first, with the undated rows at the end rather than the top
GET /api/data/posts?orderBy=publishedAt:desc:last

Le format tableau JSON accepte une clé "nulls" pour obtenir le même comportement :

GET /api/data/posts?orderBy=[{"field":"publishedAt","direction":"desc","nulls":"last"}]

Toute valeur autre que first ou last renvoie une erreur 400, et non un ordre silencieusement altéré. Le curseur ci-dessous respecte la déclaration du tri, de sorte que la pagination sur une clé nullable reste correcte quel que soit l’emplacement choisi.

Pagination

Utilisez limit et offset, ou page :

# Limit and offset
GET /api/data/products?limit=20&offset=40

# Page-based (uses the default limit of 50)
GET /api/data/products?page=3

La limite par défaut est de 50, le maximum est de 1000. Ces deux valeurs proviennent de DEFAULT_LIST_LIMIT / MAX_LIST_LIMIT, également indiquées dans la spécification OpenAPI générée — une valeur limit supérieure au maximum est rejetée plutôt que tronquée.

Ces trois paramètres de fenêtre sont rejetés plutôt que corrigés automatiquement, et chacun renvoie une erreur explicite : INVALID_LIMIT, INVALID_OFFSET (un entier supérieur ou égal à 0) et INVALID_PAGE (un entier supérieur ou égal à 1). Une fenêtre silencieusement différente de celle demandée ne peut pas être distinguée de la fin de la collection, c’est pourquoi aucun d’eux n’est tronqué ni ignoré.

Pagination par curseur

offset recompte les lignes à chaque requête, de sorte qu’une ligne insérée ou supprimée entre deux pages décale la fenêtre et le parcours saute ou répète silencieusement des lignes. ?after= effectue plutôt une recherche directe : la page suivante commence strictement après la dernière ligne servie.

Chaque réponse de liste contient meta.nextCursor tant qu’il reste une page suivante. Renvoyez-le tel quel :

GET /api/data/orders?orderBy=createdAt:desc&limit=100
# → meta.nextCursor = "eyJrIjpbWyJjcmVhdGVkX2F0Iiw…"

GET /api/data/orders?orderBy=createdAt:desc&limit=100&after=eyJrIjpbWyJjcmVhdGVkX2F0Iiw…

Le curseur est opaque — il encode les clés de tri et les valeurs de la dernière ligne pour celles-ci — ce qui implique trois règles, chacune renvoyant une erreur 400 plutôt qu’une page incorrecte :

Situation	Code
after avec offset ou page	CURSOR_WITH_OFFSET — les deux indiquent où commence la page
after avec un orderBy différent de celui sous lequel il a été émis	CURSOR_ORDER_MISMATCH
Un curseur que cette API n’a pas émis	INVALID_CURSOR

Une requête qui ne précise aucun orderBy adopte celui du curseur, donc renvoyer meta.nextCursor sans redéfinir le tri fonctionne.

Les tris multi-clés et les clés nullables se paginent tous deux correctement : la comparaison est construite sur chaque clé dans l’ordre, avec le placement des NULL déclaré par le tri. Le seul ordonnancement qu’aucun curseur ne peut décrire est la pertinence (_score) — calculée par requête et stockée nulle part — et une telle liste ne contient tout simplement aucun nextCursor.

Sélection de colonnes

?fields= restreint la lecture aux colonnes que vous spécifiez. Il s’agit d’une projection intégrée à la requête, et non d’un simple découpage de la réponse :

GET /api/data/posts?fields=id,title&limit=50

La clé primaire est toujours retournée (une ligne qui ne peut pas être ciblée ne peut être mise à jour, supprimée ou dépassée par pagination — et le curseur en dérive), et les colonnes excludeFromApi restent masquées, qu’elles soient nommées ou non. Une colonne inconnue renvoie une erreur 400 UNKNOWN_FIELD plutôt qu’une ligne omettant discrètement un champ.

?distinct=true fusionne les lignes identiques sur ces colonnes :

# The statuses actually in use
GET /api/data/posts?fields=status&distinct=true

Cette option est refusée (400) lorsqu’elle est utilisée avec un searchString ordonné ou une recherche vectorielle, qui attribuent un score par ligne rendant chaque ligne distincte par nature, ainsi que lorsque orderBy nomme une colonne non retournée par fields (DISTINCT_ORDER_BY_NOT_SELECTED) — Postgres ne peut pas ordonner une lecture DISTINCT selon une expression hors de sa clause SELECT.

?fields= et ?distinct= fonctionnent également sur la route d’obtention par ID et sur les routes de sous-collections imbriquées.

Format de réponse

Les réponses de liste incluent des métadonnées de pagination :

{
    "data": [
        { "id": 1, "name": "Widget", "price": 29.99 },
        { "id": 2, "name": "Gadget", "price": 49.99 }
    ],
    "meta": {
        "total": 150,
        "limit": 20,
        "offset": 0,
        "hasMore": true,
        "nextCursor": "eyJrIjpbWyJpZCIsImRlc2MiXV0sInYiOnsiaWQiOjJ9LCJpIjoyfQ"
    }
}

nextCursor est présent tant que hasMore est vrai et que la page a retourné au moins une ligne ; il est absent sur la dernière page et lors d’un ordonnancement qu’aucun curseur ne peut décrire.

Les réponses pour une entité unique retournent un objet plat :

{
    "id": 1,
    "name": "Widget",
    "price": 29.99,
    "createdAt": "2026-01-15T10:30:00Z"
}

Erreurs

Chaque échec, quelle que soit la route, est renvoyé dans une enveloppe unique :

{
    "error": {
        "message": "Unknown filter operator 'contains' on field 'title'.",
        "code": "UNKNOWN_FILTER_OPERATOR",
        "details": { "field": "title", "operator": "contains" },
        "requestId": "9f1c0b8e-4d2a-4e1b-9d0f-2c7a5b3e6a11"
    }
}

message et code sont toujours présents. details apparaît lorsque le refus concerne un élément spécifique — le champ erroné, les chemins ayant échoué. requestId apparaît lorsque la requête comportait un en-tête X-Request-ID ou s’en est vu attribuer un ; il est également renvoyé dans l’en-tête de réponse, et c’est l’élément à mentionner dans un rapport de bogue.

Faites vos branchements logiques sur code, jamais sur message ou sur le statut seul. Les codes sont en SCREAMING_SNAKE_CASE et stables ; les messages sont rédigés pour une personne consultant une console et peuvent évoluer. Le statut HTTP se trouve sur la réponse, pas dans le corps.

Statut	Code type	Signification
400	BAD_REQUEST, VALIDATION_ERROR, INVALID_LIMIT, INVALID_OFFSET, INVALID_PAGE	La requête est malformée ou demande quelque chose d’impossible
401	UNAUTHORIZED	Aucun identifiant fourni, ou identifiant qui ne correspond à personne
403	FORBIDDEN, DB_PERMISSION_DENIED	Un identifiant qui correspond à quelqu’un ne disposant pas des droits
404	NOT_FOUND	L’élément ciblé n’existe pas
409	CONFLICT	Conflit d’état — une clé dupliquée, un arbre corrompu
501	varie	La surface existe mais n’est pas configurée sur ce déploiement
503	SERVICE_UNAVAILABLE	Une dépendance est indisponible ; la requête ne l’a jamais atteinte

Une surface absente parce que ce déploiement ne l’a pas activée renvoie un code 501 avec un code et une raison, et non un 404 — un 404 inexpliqué sur une route que l’interface vient d’appeler évoquerait un déploiement défectueux.

Les routes ajoutent leurs propres codes plus spécifiques en plus de ceux-ci (EMAIL_EXISTS, TOKEN_EXPIRED, UNKNOWN_FILTER_OPERATOR, …), considérez donc la liste des codes comme évolutive. Le SDK client les convertit tous en une unique RebaseApiError contenant status, code et details — voir Gestion des erreurs.

Recherche textuelle

Utilisez searchString pour la recherche plein texte sur les champs de type chaîne :

GET /api/data/products?searchString=wireless%20keyboard

Recherche vectorielle

Si une collection définit une propriété de type vector, vous pouvez effectuer des recherches de similarité à grande vitesse à l’aide des opérations de distance pgvector compilées directement dans la requête en base de données.

GET /api/data/products?vector_search=embedding&vector=[0.15,0.22,-0.05]&vector_distance=cosine&vector_threshold=0.8

Paramètres de requête vectorielle

Paramètre	Type	Description
vector_search	string	Le nom de la propriété vectorielle sur laquelle effectuer la requête.
vector	string	Un tableau de flottants sérialisé en JSON représentant le vecteur de requête.
vector_distance	string	La métrique de distance à évaluer. Valeurs prises en charge : cosine (par défaut, <=>), l2 (<->), inner_product (<#>).
vector_threshold	number	Seuil de distance maximal. Seuls les enregistrements ayant une distance inférieure à ce seuil sont retournés.

Inclusion de relations

Utilisez le paramètre include pour intégrer des entités liées :

# Include specific relations
GET /api/data/articles?include=author,categories

# Include all relations, one hop deep
GET /api/data/articles?include=*

# A relation of a relation — up to three hops
GET /api/data/articles?include=comments.author

Un nom qui ne correspond pas à une relation de la collection renvoie une erreur 400 UNKNOWN_RELATION, à tous les niveaux. Auparavant, cela était ignoré et répondait 200 en omettant simplement le champ — ce qui était impossible à distinguer d’une ligne n’ayant réellement aucune ligne liée, de sorte qu’une faute de frappe ressemblait à des données vides. Un chemin de plus de trois sauts renvoie INCLUDE_TOO_DEEP.

Filtrer une relation spécifique

La forme séparée par des virgules ne permet pas de définir un limit par relation, c’est pourquoi include accepte également du JSON — distingué par une accolade ouvrante :

GET /api/data/posts?include={"comments":{"limit":5,"where":{"published":["==",true]},"orderBy":"createdAt:desc","fields":["id","body"],"include":{"author":true}}}

Clé	Signification
limit	Lignes par ligne parente, et non sur l’ensemble de la page
where	Le même dialecte de filtre que celui utilisé par le where de premier niveau
logical	Un groupe or/and/not sur les lignes liées
orderBy	La même syntaxe de tri, y compris le positionnement des NULL
fields	Colonnes de la ligne liée ; sa clé primaire est toujours conservée
include	Relations de la ligne liée, à leur tour

true signifie « charger en totalité », de sorte que {"author":true} et author correspondent à la même requête. Les deux syntaxes fonctionnent sur la route de liste, la route d’obtention par ID et les routes de sous-collections imbriquées.

Chaque saut correspond à une seule requête groupée pour l’ensemble de la page, jamais une par ligne.

Les relations incluses sont intégrées directement dans la réponse :

{
    "id": 1,
    "title": "Getting Started",
    "authorId": 42,
    "author": {
        "id": 42,
        "name": "Jane Doe",
        "email": "jane@example.com"
    }
}

Écriture

Les clés d’idempotence, les écritures conditionnelles (ETag / If-Match), les opérations sur les champs ($inc, $push, $pull, $merge), l’upsert sur une clé naturelle, Prefer: return=minimal ainsi que le point de terminaison multi-collections POST /api/data/_batch sont tous détaillés sur une page dédiée : Écriture via REST.

Pipeline des hooks de cycle de vie

Sur Postgres, chaque mutation REST (POST, PATCH, DELETE) exécute les callbacks de sa collection dans l’ordre, dans l’unique transaction qui porte l’écriture :

Request ──► BEGIN ──► beforeSave/beforeDelete ──► DB operation ──► afterSave/afterDelete ──► COMMIT ──► Response

Chaque hook est attendu, et une exception levée par l’un d’eux annule toute l’écriture :

1. beforeSave, beforeDelete s’exécutent avant l’écriture. Ils peuvent modifier les valeurs entrantes, valider, ou refuser la requête en levant une erreur — l’appelant reçoit 400 CALLBACK_REJECTED et rien n’est écrit.
2. afterSave, afterDelete s’exécutent après l’écriture mais avant le commit. Une exception annule la ligne et répond le même 400, avec details.stage nommant le hook. Ils gardent la transaction ouverte pendant leur exécution : ce n’est donc pas l’endroit pour un webhook ni pour aucun autre appel réseau. Hooks indique où va ce travail.

Points de terminaison système

Méthode	Chemin	Auth	Description
GET	/health and /api/health	aucune	Vérification de liveness/readiness
GET	/api/docs	aucune	La spécification JSON OpenAPI 3.0
GET	/api/swagger	aucune	Swagger UI. Activé en développement, désactivé en production ; REBASE_ENABLE_SWAGGER permet de forcer l’un ou l’autre
GET	/api/meta/schema-version	aucune	Le hash du schéma à partir duquel ce backend a été construit — délibérément sans authentification, et il ne retourne que ce hash
GET	/api/meta/contract	admin, clé de service ou clé API admin	Le contrat complet des collections, pour rebase generate-sdk --from. Sécurisé par défaut : 404 lorsqu’aucune authentification n’est configurée
GET	/metrics	REBASE_METRICS_TOKEN si défini	Métriques Prometheus, lorsque REBASE_METRICS=true

OpenAPI / Swagger

La spécification OpenAPI est générée automatiquement à partir des définitions de vos collections : elle décrit les points de terminaison de liste, de lecture, de création, de mise à jour, de suppression et en bloc de chaque collection gérée par le backend, avec leurs paramètres de requête et schémas de réponse. Il ne s’agit pas d’une cartographie complète de la surface HTTP — les routes d’authentification, de stockage, de fonctions et de cron sont documentées uniquement sur ce site — et les colonnes marquées excludeFromApi en sont exclues.

Les clients automatisés s’authentifient avec une clé restreinte plutôt qu’avec une session : Clés API.

Métadonnées de schéma

Le schéma complet des collections du projet — chaque collection, propriété et relation — est accessible à un administrateur authentifié :

GET /api/meta/contract

Il est réservé aux administrateurs, et sur un déploiement où aucune authentification n’est configurée, il n’est pas du tout accessible (404 CONTRACT_UNAVAILABLE) plutôt que d’exposer le schéma à tous. Son point de terminaison homologue renvoie une chaîne de version représentant le schéma sans le décrire, et est délibérément accessible sans aucun identifiant — ce qu’un job CI interroge régulièrement :

GET /api/meta/schema-version

Pour connaître la forme des points de terminaison plutôt que le schéma sous-jacent, le document OpenAPI est accessible via GET /api/docs, avec l’interface Swagger UI sur /api/swagger lorsque enableSwagger est activé.

Prochaines étapes

• SDK Client — Client typé pour l’API REST
• Collections — Définissez votre schéma de données
• Règles de sécurité (RLS) — Contrôlez l’accès ligne par ligne

---