Voxta Accounts & access
Passwords, API keys, and which programs on your machine are allowed to be you.
The passwordless account
A fresh install works immediately because the root account has no password, and Voxta signs it in without asking.
That is not a weak credential — it is the absence of one. On a loopback port, "whoever asked" means every process on the machine: your browser, a game mod, a stray script, anything bundled with something else you installed. None of them can be told apart by looking at the request, because nothing in a request distinguishes a local program you trust from one you don't.
Allow external apps
Allow external apps is the account's answer to that. It is asked during registration and can be changed later under Account Security.
- On — anything on the machine can sign in with no credential. Needed if you run the VAM plugin, Voxy, or your own scripts without giving them keys.
- Off — nothing signs in without one.
The flag only means anything while the account has no password. Once there is one, a client authenticates on its own merits with an API key, and the flag is simply how that client is expected to connect.
The desktop and mobile apps are the exception. They issue a one-off secret at launch and hand it to their own window, so the app you started still works with the flag off. A server you launched yourself from a terminal issues nothing — there is no host process to hold it — and permits as it always did.
Turning it off without breaking your clients
Order matters. A client with no key sends no credential at all, so withdrawing the grant first cuts it off.
Issue an API key per client
Profile menu → API keys. One per client, so you can revoke one without touching the rest.
Configure each client with its key
Anything built on the Voxta client library takes one; whether a given app exposes that in its own settings is a question for that app.
Confirm they still work — with the flag still on
An API key authenticates on its own merits, so nothing about it depends on the flag. If a client works now, it will work after.
Upgrading from an older install
The migration turns the flag on for accounts that already had no password. Their local clients depend on that grant today, and silently removing it would break a working setup to protect against something the user had already accepted.
Accounts that have a password are left off.
Requests from other websites
A separate problem, and it is closed by default with nothing to configure: a page on another site making your browser call Voxta on your behalf.
CORS does not stop this — it governs whether the browser hands the response back, not whether the request goes out, and some request shapes go out with no preflight at all. Voxta refuses API requests that a browser says it made for another site. Browsers report this and cannot lie about it, which is what makes the check reliable.
If you are deliberately building a web app against Voxta, its origin goes on the allowed-origins list.