Overview
A platform runs many client sites; each gets its own narrow, revocable slice.
Updated
On this page
The problem this solves
An agency-style platform runs many client websites. Giving every site the platform key would mean one compromised site exposes every client, and offboarding a churned client means rotating everything. So sites get their own keys, reaching their own surface.
The shape
Platform
└─ website record (the site, in the fleet)
└─ dfd-site-secret-key-live-… server-side, full site surface
└─ dfd-site-public-key-live-… browser-safe, read-only + lead/form submits, origin-locked
└─ /api/site/* whoami, content, files, products, categories,
locations, forms, leads, insights, cdn
- The "site" is a
websiterecord — fleet data the platform already manages — so keys hang off that record rather than a second site table, and deleting the site kills its keys. - Keys are scoped to the site's customer, so site-surface reads see that client's slice (plus deliberately shared pools like brand assets).
- A site key can never call the platform dashboard API — the namespace reaches
/api/site/*only.
What a client site can do
| Area | Capability |
|---|---|
| Content | Managed copy and blog posts edited in the dashboard; site-specific rows beat shared ones. |
| Files | The site's file slice + shared brand assets, by stable label, as plain CDN URLs. |
| Catalog | Active products and categories (display-only), site-scoped with a shared pool. |
| Locations | The client's business profile: name, addresses, per-location labeled files. |
| Forms & leads | Fetch dashboard-built forms by key; submit forms and contact-form leads (validated, throttled, honeypotted). |
| Insights | Send the first-party analytics beacon. |
| CDN | Deploy its own static assets (manifest / upload / activate / status). |
| whoami | Site, customer, platform, environment, modules. |