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.