Cannot Log in
When a login attempt fails, the form clears with no error message. There is no indication of what went wrong, because the system does not reveal whether a submitted key exists. Work through these checks in order to find the cause.
Check the key format first
Your access key is exactly 32 characters long. Count them. If you count fewer than 32, the key was truncated — perhaps the copy stopped at a line break, or the source only showed part of the key. If you count more than 32, there is a leading space, a trailing space, or a newline character that was captured along with the key.
The 32 characters are all hexadecimal: the digits 0 through 9 and the lowercase letters a through f. If the string contains a capital letter, a hyphen, an underscore, a space in the middle, or any character outside [0-9a-f], it is either the wrong string or a version of the key that was modified in transit through another application.
Paste the key into a plain-text editor — not a word processor, not a notes application that applies formatting — and count the characters manually. Plain text editors show invisible characters like trailing newlines more reliably than rich-text fields. Once you have confirmed 32 clean hexadecimal characters, copy from the plain-text editor into the login form.
Common paste-related problems
Terminal emulators often add a trailing newline when you copy a line of output. If you stored your access key in a terminal command or shell variable and are copying from the terminal history, the copied string may end with a newline character that is invisible but present. The login form will see 33 characters — 32 plus a line feed — and reject the submission silently.
Rich-text applications — Google Docs, Notion, Word, Apple Notes with formatting — sometimes apply smart quotes or substitute characters when pasting text that looks like a URL or a code string. If your key passed through one of these applications at any point, check whether any of the hexadecimal characters were substituted for similar-looking characters. The digit 0 and the letter O look identical in some fonts; the digit 1 and lowercase L look nearly identical. Use your plain-text editor to verify each character class.
Password managers sometimes autofill fields unexpectedly, replacing your manual paste with a different stored credential. If your password manager is active in the browser, disable autofill for the login field or copy the key explicitly and paste it with the manager's autofill disabled.
Browser and extension interference
Some browser extensions intercept form submissions. An extension that inspects or modifies POST requests could alter the key value between your paste and the server receiving it. Test in a private browsing window with extensions disabled. If login succeeds there but not in your normal browser profile, an extension is the likely cause.
Browser autofill may also interfere. If the browser has previously filled the login field with a different value, it may silently replace your paste with the stored autofill value. Disable browser autofill for the login page and paste the key manually.
If you are behind a corporate proxy or a content inspection device, the device may be modifying or stripping HTTPS request bodies. This is rare, but if you are in a managed network environment and login consistently fails despite a correct key, try from a network you control, such as a mobile data connection, to isolate the network as a variable.
If the key itself may be wrong
If the format checks pass and the paste environment is clean, the key you are submitting may simply not match the account on file. This happens when a key has been regenerated since you last saved it — the old key is permanently invalid after regeneration — or when the saved string was never the correct key to begin with.
If you believe regeneration may have occurred since your last successful login, the new key was shown on the regeneration confirmation page. Search your password manager for the most recently added or modified entry for statelessid.com. If the stored key predates the regeneration, it will not work. In that case, if you can reach the admin panel by another active session, regenerate again and save the new key immediately.
Troubleshooting
If you have been through all the format and environment checks and login still fails, open the browser developer tools, go to the Network tab, submit the login form, and look at the request. Check that the submitted key value in the request body is exactly 32 characters of [0-9a-f] with no encoding artifacts. If the value looks wrong in the network request, the problem is in how the browser is capturing or encoding the field value. If the value looks correct and the server still returns a failure response, the key does not match the account.
If you have genuinely lost access to the key and cannot complete payer rekey from the login page, recovery requires proving subscription ownership through the payment processor — not email on file with us, because we do not keep it.