Restrict a key to allowed origins
An allowed-origins list tells Syntic which websites may use a key from a browser. Once a key has at least one origin, a request is only accepted when the browser’s Origin header (or, if that’s missing, the Referer header) matches the list.
Where to set it
- In the Console: on API Keys → Create API Key, choose the Public type. An Allowed origins box appears.
- In the main Syntic app: under Settings → API Keys, the Allowed Origins box is offered for both private and public keys.
Enter one origin per line. Leave the box empty to allow every origin.
You can only set origins when you create the key. To change them later, create a new key with the right list and revoke the old one.
How entries are matched
| You enter | What is stored or matched |
|---|---|
https://shop.example.com/checkout | Paths are dropped: https://shop.example.com |
shop.example.com | No scheme means https://shop.example.com |
https://shop.example.com:443 | Default ports are ignored, same as https://shop.example.com |
https://*.example.com | Any subdomain, such as https://eu.example.com, but not https://example.com itself |
Only the scheme, host and port are compared. Add the bare domain as its own line if you need it too.
If an entry can’t be understood, key creation fails with a message like “Not a valid origin: … Use https://app.example.com or https://*.example.com.”
Server calls stop working
Once a key has an origin list, requests that carry no Origin or Referer header are refused. Server code, scripts and command-line tools usually send neither, so an origin-restricted key effectively works only from a browser. The error is HTTP 403 with the code origin_not_allowed.
Keep the list empty on keys your backend uses.
An origin list is not a lock on a secret. Anyone who copies a key out of a web page can call the API from their own server and send any headers they like. Keep private keys out of browser code entirely.