Site keys

Issuing

Keys are issued from the platform dashboard, on the website's keys panel. The value is shown once; storage is hash + encrypted copy, the same contract as platform keys. Format:

dfd-site-secret-key-live-<random>    server-side only, full site surface
dfd-site-public-key-live-<random>    browser-safe; read-only + submits; origin-locked
dfd-site-secret-key-test-<random>    local development (skips the origin allowlist)

Scoping

• A key belongs to one website record and carries the site's customer — reads on the site surface are scoped to that client (their locations, their catalog slice, their submissions), plus shared pools the platform deliberately publishes to all its sites.
• Site keys are paired to their platform: a key from any other platform is rejected on first use.

Public vs secret, on a site

• Secret — lives in the site's server env (LPS_SITE_KEY-style, never NEXT_PUBLIC_*). Full surface, including CDN deploys.
• Public — may ship in the browser bundle. Read-only except lead and form submits, which are visitor input by nature; locked to allowed origins managed per key.

Client SDKs enforce the split mechanically: constructing a browser client with a secret key throws immediately.

Revocation & offboarding

• Revoking a key cuts off that one site. Nothing else is affected.
• Deleting the website record deletes its keys with it (cascade).
• A churned client is: revoke keys, archive the customer — done. Their data stays intact for any wind-down obligations.