The key hierarchy
pk_/sk_, dfd-platform-*, dfd-site-* — three namespaces, one philosophy.
Updated
On this page
Three namespaces
| Namespace | Belongs to | Reaches |
|---|---|---|
pk_… / sk_… | A storefront organization | The storefront API |
dfd-platform-<kind>-key-<env>-… |
pk_/sk_, dfd-platform-*, dfd-site-* — three namespaces, one philosophy.
Updated
| Namespace | Belongs to | Reaches |
|---|---|---|
pk_… / sk_… | A storefront organization | The storefront API |
dfd-platform-<kind>-key-<env>-… |
| A platform's own dashboard/portal |
/api/platform/*, gated by module grants |
dfd-site-<kind>-key-<env>-… | One client website | /api/site/* only — never the platform API |
The namespaces are deliberately disjoint so a leaked value is instantly identifiable as what it is. A platform key in a website is a configuration bug the format makes visible at a glance.
NEXT_PUBLIC_* variable.Key values are minted with 32 bytes of entropy and shown exactly once. Storage is a SHA-256 hash (every lookup goes through it — the plaintext is never used in a query) plus an encrypted copy that superadmins can re-reveal only behind a verified sensitive-operation check, with the reveal landing in the audit log. Dashboards display keys masked to their last four characters.
last_used_at and a request counter (updated atomically), so a dead key is visibly dead before you revoke it.