- Shipped
- September 5, 2026 at 8:31 PM UTC
- Author
- Kamo
- Commit
- bd608ed
`publicSiteKey` was persisted only for SPECIFIC_AGENT integrations, because the multi-tenant MLOS portal was the only page that had to resolve its key by Host rather than carry it in its own HTML. The public loan application is the second: one deployment serves every lender, and the key is chosen by the product id in the URL. So `hostedKey` on create opts an integration into the same treatment, and `POST /{id}/hosted-key` gives one to an integration that already exists. That second one ROTATES. A key hash is 1:1 with an integration, so there is no way to add a second key to one — the old key stops working the moment it returns. The settings screen states that and takes a confirmation first; an integration that has never been embedded loses nothing, and one that has is the operator's call. It is idempotent where a hosted key already exists, so opening the picker twice cannot break a working page, and it carries the previous key's origin lock and rate tier forward rather than re-deriving them — quietly widening an origin-locked key at the moment it goes on a public page is the wrong direction to be careless in. Persisting it is safe and already argued in the code this extends: a site key is public by design — origin-locked, PUBLIC_CHAT-scoped, rate-limited — and already ships in the HTML of every page that embeds it.