- Shipped
- September 5, 2026 at 11:27 PM UTC
- Author
- Kamo
- Commit
- 1633a56
The support widget on a published application loaded with Kamo's default config instead of the org's: it auto-opened on desktop with auto-open turned off, wore Kamo's colours, and showed Kamo's branding on a page carrying the lender's logo. A public-chat site key can be origin-locked, and the gateway enforces that lock on the widget's first call. The origins on the key are the ones the operator typed when they created the integration — their own marketing site. Nothing told them that publishing an application also serves it from apps.<their domain> and apps.kamocrm.com, so the bootstrap came back 401. The widget does not surface that. On a 401 it falls back to its built-in defaults, which is why the symptom was a setting being ignored rather than a chat that failed to load, and why nothing anywhere said the key was refused. Publishing now adds both application origins to the key itself, and drops the gateway's cached copy so the operator's first look at the page shows the fix rather than the same broken widget for another minute. A key with a BLANK allow-list is left alone: blank means "any origin", so it already permits the application page, and writing our two origins in would convert an open key into a locked one and silence the site embedding it today.