Privacy

Last updated 24 September 2026.

AutoAuthAPI holds two-factor secrets, so it is worth being exact about what is stored, what never is, and how to get rid of all of it.

What is stored

Data	Why	How
Your email address	It is your username, and the only way to recognise your account.	Plain text.
Your password	To sign you in.	Salted hash (scrypt). The password itself is never written down.
Your API key	To authenticate machine requests, and to re-show the key in your vault.	A SHA-256 hash for lookup, plus a Fernet-encrypted copy so the vault can display it again.
Your TOTP secrets	To compute your codes.	Fernet-encrypted (AES-128-CBC + HMAC-SHA256). The encryption key is held outside the database.
Issuer and label	So you can tell your entries apart.	Plain text — whatever you typed or the QR code contained.
Account creation time	Housekeeping.	Timestamp.
Account status	The operator can disable an account, for example when it is being abused. While it is disabled nobody can sign in to it and its API key is refused; nothing in it is deleted.	The time it was disabled, or nothing.
Operator action log	A record of what the operator did to an account — signing it out everywhere, replacing its API key, disabling, re-enabling or deleting it — so every such action can be checked afterwards.	The action, when, the account’s id and its email address as it was at that moment, and the operator’s own IP address. Kept when the account is deleted, because it is the record that the deletion happened, and not removed automatically.
Recent attempts (rate limiting)	To slow down password guessing and keep one account's API traffic from crowding out anyone else's.	The time of each recent sign-in attempt, signup, reset request and API or vault request, with the IP address or the account it counted against. A failed sign-in is recorded under a keyed hash of the address typed, never the address itself. A wrong password re-entered to change a password, to export an entry, to delete the account, to change sign-in methods, or by the operator to confirm an account action, is counted against the account and against the IP address, for ten minutes. The operator’s own attempts at the actions in the operator action log are counted too, against the operator’s account, for ten minutes; that count is not the log, which records only actions that changed something. Kept until the limit it counts toward has run its course: one minute for API and vault requests, ten minutes for sign-in, signup, and password re-checks (including attempts to connect Google), and one hour for password reset requests. Expired entries are then deleted and overwritten — in the file and in its write-ahead log — by a clean-up that runs about once a minute while the service is in use and the request that follows it; never included in a backup.

If you use Continue with Google, AutoAuthAPI receives and stores only two things from Google — your email address and your Google account ID — and never your name, photo, contacts or Google password. Alongside them it keeps one yes/no flag: whether Google vouched that the Google account owns this AutoAuthAPI account's email address (true for Gmail and Google Workspace addresses).

What is never stored

• Generated codes. Every code is computed at the moment you ask for it and then discarded. There is no log of codes issued.
• QR screenshots. Images you drop into the vault are decoded by JavaScript in your own browser. The image is never uploaded — only the otpauth:// string it contains is sent, over HTTPS.
• Payment details. AutoAuthAPI is free and asks for no card.
• Analytics, advertising or tracking cookies. There are none, and no third-party scripts of any kind. The only cookie is the session cookie that keeps you signed in.

Who can see it

• You. Through the web vault, or the API with your key.
• Whoever holds your API key. It unlocks every code in your vault — that is the deliberate trade-off AutoAuthAPI exists to make. It does not unlock the secrets behind those codes: there is no export route on the API, so a leaked key can be fully revoked by rotating it from Your API. Treat it like a password.
• Nobody else. Vaults are scoped to their owner at the database-query level; another account asking for one of your ids gets a 404. Your data is never sold, rented, or shared with third parties, and it is not used to train anything.
• Operators, in principle. Whoever runs the server holds the encryption key, so a determined operator could decrypt stored secrets. That is true of every hosted authenticator. If that is not an acceptable risk for you, do not put your most critical accounts in a hosted vault — keep those on a device-only authenticator and use AutoAuthAPI for the automation accounts it is built for.

Getting your secrets out

Your TOTP secrets are yours, and you can take them with you. Each entry in your vault has an Export link that shows the setup QR code and the otpauth:// URI behind it, which any authenticator — Google Authenticator, Authy, 1Password, Aegis, Bitwarden — can import. Exporting does not remove the entry from AutoAuthAPI.

Be clear about what comes out. An export gives you the seed itself, in plain text — the QR code, the base32 setup key and the otpauth:// URI are three renderings of the same secret, and nothing encrypts or wraps any of them. It is a bearer credential: anyone who ends up with it — from a screenshot, a photo of your screen, your clipboard, a screen share — can generate valid codes for that account indefinitely, without your password and without touching AutoAuthAPI at all. It cannot be revoked. The only way to invalidate an exported seed is to turn two-factor off at the site it belongs to and set it up again, which issues a new one. AutoAuthAPI produces no file and keeps no extra copy; once it is on your screen, where it goes next is outside anything we control.

Because of that, the path to it is deliberately narrow — it is the only one in the whole service that reveals a stored secret rather than a code:

• It asks for your password, on the request that returns the secret — not merely at some earlier point in your session. A stolen session cookie on its own gets a password prompt, not a seed.
• The API cannot do it at all. There is no export endpoint on /api/. An API key lives in CI config and shell history, so it is the credential most likely to leak; keeping seeds out of its reach is what makes rotating a leaked key a complete fix rather than a partial one.
• One entry at a time. There is no “download everything” button, so no single click or mistaken tap can spill a whole vault.
• The QR code is drawn in your browser, from the URI, by a script served from this site. No picture of your secret is ever generated on the server, so none can be cached or logged along the way.

Deleting your data

• Removing an entry in the vault deletes its encrypted secret immediately and permanently. There is no soft delete and no recycle bin.
• To delete the whole account — the login, the API key and every stored secret — open your vault and use Delete my account at the bottom of the page (autoauthapi.com/app). It asks for your password and for your email address typed out, then deletes the entries and the account itself in a single step. It takes effect immediately: the API key stops working at once, and there is no backup, no soft delete and no recycle bin. Nobody here can reverse it afterwards.
• Before you delete, make sure you can still get into the sites those codes belong to. Deleting an entry does not turn two-factor off at the site itself — that site will still ask for a code. Use Export on anything you still need first (see above), or re-enrol it in another authenticator, or save the site's recovery codes. The deletion page lists exactly which entries are about to go.
• If you cannot sign in and so cannot reach that page, email privacy@autoauthapi.com from the address you signed up with and ask for the account to be deleted. The operator deletes it the same way, in a single step, and emails the address a notice. The operator’s action log keeps one line recording that the deletion happened, with the email address the account had (see What is stored).

Security notes

• All traffic is HTTPS. The session cookie is HttpOnly, SameSite=Lax and Secure. A session lasts 14 days from when you sign in, and resetting your password or rotating your API key signs out every other browser. We email you whenever a Google account is connected to yours, and a password reset disconnects one that was connected with only your password. The first password reset on an account whose address had never been confirmed also replaces its API key.
• The site sets frame-ancestors and X-Frame-Options so no other origin can frame your vault.
• No API endpoint returns a stored TOTP secret. Secrets leave AutoAuthAPI by exactly one route — Export, in the browser, with your password, one entry at a time.
• Sign-in and signup are rate limited per IP. An account that collects many failed sign-ins gives each network only a few more tries at it (an IPv4 address, or an IPv6 address's whole /64), while a correct password from a network that has not been guessing at it still works.

Children

AutoAuthAPI is not intended for anyone under 13, and accounts are not knowingly created for them.

Changes

If this page changes materially, the date at the top changes with it.

Contact

Alpha Marketing Group — privacy@autoauthapi.com.