Allowed origins

Every key has an optional list of allowed origins: the domains (hostnames) it’s accepted from when the request arrives with an Origin header (that is, from a browser). The format is the bare hostname, without https:// or a path — for example myapp.mydomain.com, never https://myapp.mydomain.com/.

Empty = no origin restriction (the default value, and the one the “Allowed origins” column shows as “No restriction”): the key works from anywhere. Restricting the origin makes sense when the key is going to be used from a browser frontend (for example, your own widget calling the API with this key embedded) and you want to reduce the damage if that key leaked — it limits which web domains can use it.

Note — It isn’t a defense against everything

The origin check only applies when the request carries the Origin header (typical of a browser). A server-to-server call — an API key’s main use case — usually doesn’t send that header, so it goes through regardless of whether the origin list is restricted. It’s a layer against abuse from a browser, not the main secret protecting the key: that’s still the key itself.

The “New key” form (section 4) comes with the “Allowed origins” field already filled in with * — no need to touch it if “no restriction” works for you. To restrict it, replace it with a comma-separated list of hostnames (for example myweb.com, app.myweb.com — each one also covers its subdomains), without https:// or slashes; the limit is 50 origins per key. A value that isn’t a valid hostname (with https://, with a path, with spaces…) gives an immediate error right in the form, before sending the code.