Origin allowlists
For a publishable key, the origin allowlist is the security. The key itself is public.
Syntax
One entry per line.
| Entry | Matches | Does not match |
|---|---|---|
example.com | http:// and https://, any port | www.example.com |
https://example.com | https only | http://example.com |
example.com:8443 | that port only | other ports |
*.example.com | app.example.com, www.example.com | example.com, a.b.example.com |
Rules worth knowing
Wildcards match exactly one level. *.example.com covers app.example.com
but not a.b.example.com. Multi-level wildcards are how a forgotten allowlist
entry becomes “anyone who can register a subdomain can spend your quota”.
A wildcard does not include the apex. Add example.com separately if you
serve from it.
www is a different origin. example.com and www.example.com are distinct.
Add both, or use a wildcard plus the apex.
localhost is always allowed, on any port, without configuration. So is
127.0.0.1. A developer running npm run dev should not have to configure
anything to see your integration work.
A pasted URL is fine. https://example.com/dashboard is accepted; the path
is ignored.
Requests with no Origin
Some callers send no Origin header — curl, certain mobile webviews, a
server-side proxy. We cannot verify where those came from, so instead of
rejecting them we allow them under a hard per-IP rate limit.
If that is your server, use a secret key instead.
When something is rejected
The 403 body names the exact origin we saw, lists
what is currently allowed, and links to the settings page. Copy the
rejectedOrigin value verbatim — matching is exact, and a subtly different
subdomain is the usual cause.
Changes take effect within 30 seconds.