Security
Last updated: August 12, 2026
QuotaCanary stores third-party API keys so it can read your credit balances. This page explains exactly how those keys are handled, and is honest about what hosting model protects against what. You are about to paste something valuable, so you should be able to read this before you have an account, not after.
How keys are stored
- Keys are encrypted with AES-256-GCM before they are written to the database. GCM is authenticated encryption: a random 12-byte IV per value and an auth tag that is verified on decrypt, so tampered ciphertext is rejected.
- The plaintext key is never stored. Only
iv:authTag:ciphertextlands in the database, alongside the last 4 characters so you can tell connections apart. - The encryption key lives in the server environment, separate from the database. A database leak alone cannot decrypt anything; an attacker would also need the environment.
- Every connection row is restricted to its owner by row-level security. One account cannot read another's data, encrypted or not.
- Ciphertext never reaches the browser. Keys are decrypted server-side only at poll time, to make a single read-only call to the vendor.
- Replacing a key overwrites the old one in place. We keep no history of previous credentials.
What we do with the key
QuotaCanary makes read-only calls. It reads balances; it never modifies your accounts on connected tools, never spends credits, and never touches your contacts, leads, messages, or campaigns. It is a strictly smaller ask than the tools you already trust to act on your behalf.
Balances are checked on a schedule, roughly every 15 minutes, plus whenever you refresh a connection yourself.
The honest limit
On the hosted app, the server can technically decrypt your keys, because it has to use them to poll your balances while you are away. This is true of any hosted tool that acts on your behalf. Encryption at rest protects against a database leak; it does not mean the operator is cryptographically incapable of decryption.
If you do not want any operator to be able to decrypt your keys, self-host. Then you are the operator, you hold the encryption key, and your keys never leave your infrastructure. QuotaCanary is open source and the code is identical, so you can read exactly what it does before you trust it.
A tip that limits blast radius
Where a vendor offers it, paste a read-only or scoped API key. QuotaCanary only needs to read balances, so a scoped key means the worst case is "someone could read your balance," which is close to nothing. Plenty of vendors only issue one all-or-nothing key, in which case there is nothing to scope down and we will not pretend otherwise.
A minor note for the thorough: a few vendor adapters pass the key as a URL parameter (?api_key=), because that is the only authentication those vendors accept. Over HTTPS that is encrypted in transit; the only theoretical exposure is the vendor's own request logs, not QuotaCanary.
How long we keep things
Credentials are kept until you delete the connection or replace the key.
Balance readings are pruned after 90 days, except that the most recent 50 readings for each watched balance are always kept, so a tool you stopped polling still has a history to show you.
Alert history, tool requests, and feedback you send us are kept indefinitely. Alert history records the tool name, the name you gave the connection, and the numbers that triggered the alert. It never contains your API key.
Deleting things
Deleting a connection deletes its encrypted credential and its balance history from the live database immediately. Alert history for that connection survives the delete, because it is your record of what happened, and it keeps the tool name and connection name you chose.
Deleting your account is not yet self-serve. Email [email protected] and we will delete everything we hold about you within 30 days. Self-serve deletion is on the roadmap.
One caveat we would rather state than hide: deletion removes rows from the live database, but encrypted database backups roll off on their own schedule, so a deleted row can persist in a backup for a while after it is gone from the app.
Reporting a vulnerability
Email [email protected]. Please do not open a public issue for a security report. We will acknowledge it and work a fix with you.