Allowed origins, explained

Your site key only answers to domains you've listed. That's the security model in one sentence — here's the detail.

What an origin is

An origin is scheme + host + port: https://example.com, https://app.example.com, and http://localhost:3000 are three different origins. When the widget boots, the browser sends the embedding page's origin, and Doorwick checks it against the site key's allowlist before creating a session.

Why it exists

Your site key is public — it's in your page source, by design. The allowlist is what stops someone from pasting your key into their own site and speaking to your visitors under your name. Without a matching origin, the widget refuses to boot; no session, no conversation, no data.

Managing the list

In the dashboard, open Site keys (or the onboarding checklist's "Allow your domains" step). Add every origin that embeds the widget — apex and www are separate:

typical production allowlist
https://example.com
https://www.example.com

Input is normalized for you:

  • A bare host becomes https — example.com https://example.com
  • Scheme and host are lowercased; default ports (443/80) are dropped, custom ports kept
  • Anything with a path, query, or fragment is rejected, not trimmed — pasting a deep link never allowlists by accident

Local development

Add your dev server's origin with its port — for example http://localhost:3000. Remove it when you go live if you don't want local environments talking to your production workspace.

Who can change the list

Site keys and their origins are owner-only. An agent can work the inbox all day without ever needing this page.

Troubleshooting

The launcher doesn't appear and the console shows 403 on /widget/session: the page's origin isn't on the list. Check for the exact scheme and subdomain — www vs apex is the most common miss.

Next