Unapproved Script
A beacon is silently rejected when the site key in data-k was not registered for the hostname sending it. The page loads normally, no error appears in the browser, and no count appears in the dashboard.
How domain validation works
Every site key issued by StatelessID is bound to a specific hostname at the time of registration. When a beacon arrives, the server reads the site key from the payload and the origin hostname from the request headers. It checks whether that hostname is the one the key was issued for. If they match, the count is recorded. If they do not match, the beacon is dropped and nothing is counted.
The validation is exact. www.example.com and example.com are different hostnames. A key registered for www.example.com will not accept beacons from example.com, even if the two serve identical content and redirect to each other at the server level. The beacon carries the hostname the browser actually loaded — and that hostname must be the one registered under the key.
This validation exists to prevent a key seen in one page's source from being used to pollute a different account's dashboard counts. A site key exposed to the public can be read by anyone, but the hostname binding limits where it can send valid beacons. Someone outside your network cannot register your key for their domain and send counts to your dashboard.
Common hostname mismatches
The most frequent mismatch is between the apex domain and the www subdomain. If you registered example.com but your live site redirects all traffic to www.example.com, the beacon fires from www.example.com. A key for example.com will be rejected. Register www.example.com as a site and use its key, or register both and use each key on the correct domain.
Staging and development environments are another common source. A key registered for example.com rejects beacons from staging.example.com, dev.example.com, or localhost. If you want to track a staging environment, register it as a separate site in the dashboard and paste its key into the staging template. Do not share keys between production and staging — their counts would merge, and the key would still be rejected on the non-registered hostname.
Port numbers also matter. http://localhost:3000 and http://localhost:8080 are different origins. A key registered for localhost:3000 does not cover localhost:8080. When registering a local development domain, include the port in the hostname if your local server uses a non-standard port.
How to identify a mismatch
Open your site in a browser and look at the address bar. The hostname shown there — everything between the protocol (https://) and the first slash — is what the beacon will report. Now open your dashboard and look at the registered sites. Find the site whose key you are using in your script tag. Check that the site's registered hostname exactly matches what the address bar shows.
If they differ, you need to either register a new site with the correct hostname and use its key, or update your site registration to the hostname you are actually using. Both paths produce a valid key for the correct hostname. The old key for the incorrect hostname cannot be reassigned — keys are tied to the hostname at issuance.
Multiple domains, multiple keys
If you operate multiple domains — separate products, country-specific domains, a staging and a production environment — each needs its own registered site and its own site key. This is not a workaround or a limitation to circumvent; it is the intended model. Separate registrations give you separate visit streams, separate settings, and separate dashboard views for each hostname.
If you deliberately want to count visits from two domains in one stream — for example, if example.com and example.net serve the same product and you want to see combined counts — the correct approach is to register one domain, redirect the other to it, and instrument only the domain that visitors finally land on. A redirect ensures only one hostname appears in the beacon.
Troubleshooting
If you registered a site and immediately pasted the key into your script tag but visits are still not counting, double-check that you copied the key for the site whose hostname matches the domain you deployed to. The dashboard lists all registered sites. Click into each site's Settings → Script tab to see its key. If you have similar-looking hostnames registered — example.com and www.example.com, or two different projects — it is easy to copy the key for the wrong one.
If you run a platform that serves multiple clients from one installation with different hostnames, and you want to instrument each hostname separately, each hostname needs its own StatelessID site registration and its own key in its script tag. A single key in a shared template served across multiple hostnames will work only for the one hostname the key was registered for — all others will be silently rejected.
If you recently changed the domain where your site lives — moved from one hostname to another, changed a subdomain structure, or switched from HTTP to HTTPS with a different hostname — the key from the old registration does not carry over. Register the new hostname as a site and use the new key. Historical data from the old site remains under the old registration in the dashboard.