Data Model
The Platform API is backed by Prisma 7 over Neon Postgres. The schema is large — roughly 1,265 models across 182 schema files. This page describes the multi-tenancy model and the key tables you will meet through the API.
Multi-tenancy
Inklura is multi-tenant, and the scope is carried on the rows themselves:
tenantId(uuid) is present on every tenant-owned row — 172 of 182 schema files carry it.siteIdis present where a row also belongs to a specific site — 152 files carry it as well.
A tenant has a unique code slug (for example wd29 or fitamant) plus a status. A
tenant owns many Site rows, each with its own slug, status, and data.
Tenant isolation is enforced in application code, not by Postgres row-level security.
Queries must be scoped by tenantId (and often siteId) in code — there is no RLS backstop.
This is why the API resolves a tenant/site scope on every request (see
Sessions & Tokens).
The request-time scope maps directly onto these columns: the X-Tenant-Id / X-Site-Id
headers (or the session's selected tenant/site) select which rows a call may read or write.
See Tenancy in the Overview.
Key models
The following models are the ones you will most often touch through the API. Naming is mixed-case (see the note below).
| Model | What it is |
|---|---|
tenant |
The tenant. Unique code slug (e.g. wd29), plus status. |
Site |
A site owned by a tenant — slug, status, data. A tenant has many. |
Membership |
Links a user to a tenant. |
user |
A user — email, hashed password, optional siteId. |
Role / Permission |
Roles and perm:action permission strings. |
Account |
OAuth account links. |
Product / ProductStockAvailable |
Catalog products and their available stock. |
Order / OrderItem / OrderFulfillment |
Orders, line items, and fulfillment. |
StockAction |
The stock ledger. |
Vendor / SupplierOrder |
Vendors and supplier orders. |
Invoice |
Invoices. |
Subscription |
Subscriptions. |
Campaign |
Marketing campaigns. |
SiteDomain / SiteSettings |
A site's domains and settings. |
FeedApiKey |
A scoped, hashed key for content feeds. |
verificationtoken |
Email/verification tokens. |
Feed API keys
Some read-only subsystems authenticate with their own scoped keys instead of a user session:
FeedApiKey— a hashed key plus akeyPrefix(feed_…). Each key carries a per-hourrateLimit, anallowedIpsallowlist (CIDR), anexpiresAt, and a set ofpermissions[]. Keys are unique per(tenantId, siteId, name)and are managed via thefeedApiKeystRPC router.LiveChatApiKey— used by the embeddable live-chat widget.
These are the exception; the general API uses sessions and Bearer JWTs (see Authentication).
A note on casing
Model names are mixed-case. A few core tables are lowercase — tenant, user,
verificationtoken — while most models are PascalCase (Site, Product, Order,
Invoice, …). Match the exact casing shown above when referring to a model.