SID Key
sid-key means an access key submitted at login, or a site key submitted in a beacon, was not found in the system. For login, the form clears silently. For beacons, the visit is not counted. Neither reveals why the key was rejected.
Access key rejection at login
When you submit the login form with an access key the server does not recognize, the form clears and nothing else happens. There is no error message, no indication of whether the key was close but wrong, and no suggestion to try something different. The system responds identically whether the key has one wrong character, is the right key for a different account, is a site key rather than an access key, or is a completely random string.
Access keys are exactly 32 hexadecimal characters. If the string you are submitting is shorter, longer, contains non-hex characters (letters beyond a–f, spaces, hyphens), or has been modified by a rich-text application, it will not match any account key on the server. The login form accepts the submission, the server processes it, and the server finds no match.
The silent rejection is deliberate. A system that says "account exists but key is wrong" gives an attacker confirmation that the account exists and is worth further attempts. A system that says "account not found" reveals which key lengths and formats to avoid. Silence gives no information that helps an attacker narrow their search.
Site key rejection in beacons
When asset.js fires a beacon, the site key in data-k travels to the server. The server looks up the key and validates that the hostname in the beacon origin matches the hostname the key was registered for. If the key does not exist, the beacon is dropped. If the key exists but the hostname does not match, the beacon is dropped. In both cases, the rejection is silent: no JavaScript error in the browser, no count in the dashboard.
A site key becomes invalid if the site is deleted from the dashboard. If you remove a registered site, its key no longer exists in the system. Any pages still carrying that key will continue to fire beacons, and those beacons will continue to be silently rejected, until you remove the tag from the template. Deleting a site does not automatically scrub the key from pages that have it installed.
A site key can also produce sid-key behavior if the key in the script tag is malformed — for example, if the key was truncated when pasting, if a character was substituted, or if the wrong value was placed in data-k. The beacon reaches the server with a key that looks like a site key in format but matches nothing in the registered sites database.
How access keys become invalid
An access key becomes invalid when it is regenerated. The moment a new key is issued through the regeneration flow, the previous key is permanently invalidated. Any session, saved credential, or automation that was using the old key will encounter sid-key on its next use. The old key cannot be restored — the new key is the only credential for the account.
If you have multiple team members or automated processes using the same access key — sharing is the only option in a single-key model — a regeneration by any one of them invalidates the credential for all. Coordinate regenerations so all users are aware, and distribute the new key to all parties who need it before the old key is discarded.
The silent rejection by design
Both the login rejection and the beacon rejection are silent by design. For login: revealing whether a key exists narrows the search space for an attacker and removes the cost of invalid attempts. For beacons: a rejected-beacon error in the browser console would tell a page operator that a particular key is invalid, which is more information than an unauthenticated request should receive about server-side key state.
The consequence of silence is that when something stops working — login fails, visits stop counting — there is no error message to guide you directly to the cause. The diagnostic process is methodical: check the key format, confirm the key type (access versus site), verify the key has not been regenerated, confirm the site has not been deleted. Each check eliminates a possible cause until only the real one remains.
Troubleshooting
If login is failing and you are certain the key is correct, confirm that the key has not been regenerated since you last saved it to your password manager. The regeneration date may be after the save date on your stored credential. Log into the admin panel through an active session on another device if one exists, check the key status there, and update your password manager entry if the key has changed.
If visits from a page stopped being counted after a period of working normally, check whether the site registration still exists in your dashboard. If the site was deleted — perhaps by another user with dashboard access, or as part of a cleanup — its key is no longer valid. Registering a new site with the same hostname generates a new key. Update the script tag on the page with the new key and visits will resume.
If you are building an integration that submits access keys or site keys programmatically and receiving sid-key in response, add an explicit check that the submitted string is exactly 32 characters long and contains only [0-9a-f] before submitting. This catches the most common programmatic errors — trailing newlines from string interpolation, off-by-one truncation, or upper-cased values from a normalization step — without needing a round trip to the server.