Security & API access
Allowed domains, the public write key, and the secret keys your servers use.
The Security & API tab holds the things that decide whether Spectry accepts data for this site.
There are two different credentials here, and mixing them up is the single most common mistake:
| Credential | Write key | Server API key |
|---|---|---|
| Looks like | wk_… | sk_live_… / sk_test_… |
| Used by | The browser snippet | Your backend (Node.js SDK) |
| Public? | Yes — it is in your page source | No — never send it to a browser |
| Can do | Write events only | Read flag definitions, write events |
The two are not interchangeable, and the API rejects each one on the other's endpoints. That is deliberate: swapping them fails loudly instead of quietly publishing a secret.
Allowed domains
Data is only accepted from origins on this list. This prevents someone copying your snippet onto another site and polluting your analytics.
List every hostname the site is served from, including subdomains you actually use (www.example.com and example.com if both resolve), and staging domains if you want staging traffic tracked. If tracking works locally but not in production, a missing domain here is the first thing to check.
Write key
The write key identifies your site to the ingestion API. It appears in the tracking snippet as data-write-key, and rides the query string as ?_wk= when the browser sends a beacon on page unload (a beacon cannot set headers).
The write key is public by design — it is visible in your page source, and it must be, because the browser SDK uses it. It grants write access only: it cannot read your analytics or your flag definitions, and it is why the allowed-domains list exists as the actual protection.
Rotating the key
If you need to rotate it, generate the new key, update every snippet, then retire the old one. Traffic still using the old key stops being recorded the moment it is retired, so make the update first.
Server API keys
Backend integrations use a secret key instead — see Server API keys. They are created in the same tab, shown once, and stored hashed.
Dashboard access is separate and never uses either key — it goes through your login and per-site permissions. See Manage sites & people.