Modèle de données

L'API de la plateforme s'appuie sur Prisma 7 au-dessus de Neon Postgres. Le schéma est vaste — environ 1 265 modèles répartis sur 182 fichiers de schéma. Cette page décrit le modèle multi-tenant et les tables clés que vous rencontrerez à travers l'API.

Multi-tenancy

Inklura est multi-locataire, et la portée est portée par les lignes elles-mêmes :

  • tenantId (uuid) est présent sur chaque ligne détenue par un locataire — 172 des 182 fichiers de schéma le portent.
  • siteId est présent lorsqu'une ligne appartient aussi à un site spécifique — 152 fichiers le portent également.

Un tenant possède un slug code unique (par exemple wd29 ou fitamant) plus un statut. Un locataire possède de nombreuses lignes Site, chacune avec son propre slug, status et data.

Attention

L'isolation des locataires est appliquée dans le code applicatif, pas par la sécurité au niveau des lignes de Postgres. Les requêtes doivent être limitées par tenantId (et souvent siteId) dans le code — il n'y a pas de filet de sécurité RLS. C'est pourquoi l'API résout une portée locataire/site à chaque requête (voir Sessions et tokens).

La portée déterminée à l'exécution correspond directement à ces colonnes : les en-têtes X-Tenant-Id / X-Site-Id (ou le locataire/site sélectionné dans la session) déterminent quelles lignes un appel peut lire ou écrire. Voir la Tenancy dans l'Aperçu.

Modèles clés

Les modèles suivants sont ceux que vous manipulerez le plus souvent à travers l'API. La casse des noms est mixte (voir la note ci-dessous).

Modèle Ce que c'est
tenant Le locataire. Slug code unique (par ex. wd29), plus un statut.
Site Un site détenu par un locataire — slug, status, data. Un locataire en possède plusieurs.
Membership Relie un utilisateur à un locataire.
user Un utilisateur — e-mail, mot de passe haché, siteId optionnel.
Role / Permission Rôles et chaînes de permission perm:action.
Account Liens de comptes OAuth.
Product / ProductStockAvailable Produits du catalogue et leur stock disponible.
Order / OrderItem / OrderFulfillment Commandes, lignes de commande et préparation.
StockAction Le registre des mouvements de stock.
Vendor / SupplierOrder Fournisseurs et commandes fournisseurs.
Invoice Factures.
Subscription Abonnements.
Campaign Campagnes marketing.
SiteDomain / SiteSettings Les domaines et les paramètres d'un site.
FeedApiKey Une clé hachée à portée limitée pour les feeds de contenu.
verificationtoken Tokens d'e-mail/vérification.

Clés API de feed

Certains sous-systèmes en lecture seule s'authentifient avec leurs propres clés à portée limitée, plutôt qu'avec une session utilisateur :

  • FeedApiKey — une clé hachée plus un keyPrefix (feed_…). Chaque clé porte un rateLimit horaire, une liste d'autorisation allowedIps (CIDR), un expiresAt et un ensemble de permissions[]. Les clés sont uniques par (tenantId, siteId, name) et sont gérées via le router tRPC feedApiKeys.
  • LiveChatApiKey — utilisée par le widget de chat en direct intégrable.

Ce sont l'exception ; l'API générale utilise des sessions et des JWT Bearer (voir Authentification).

Une note sur la casse

Les noms de modèles sont en casse mixte. Quelques tables centrales sont en minuscules — tenant, user, verificationtoken — tandis que la plupart des modèles sont en PascalCase (Site, Product, Order, Invoice, …). Respectez la casse exacte indiquée ci-dessus lorsque vous faites référence à un modèle.