API key safety: how to create, store, rotate and revoke a key
An API key is a password that your code uses. Treat it like one. Most key leaks are not clever attacks: they are a key pasted into a file that was then committed, a screenshot shared in a chat, or one shared key that nobody dares to rotate because too many things depend on it. A few habits prevent nearly all of it.
One key per use
Name each key after where it lives: laptop, build server, a teammate's editor. When one leaks or someone leaves, you revoke one key and nothing else breaks.
Out of your code
Read the key from an environment variable or a secret store. Never write it into source files, config that is committed, or documentation.
Short-lived when possible
Give a key an expiry for a one-off project. A key that expires on its own cannot be forgotten.
Watch last used
A key that has not been used in months is a risk with no benefit. Revoke it.
How Tintly keys work
- A key starts with tnt_live_ followed by random characters. It is shown once, when you create it.
- We store only a fingerprint of the key, never the key itself. That is why we cannot show it again, and why a database leak would not hand out working keys.
- The list on the developer page shows the first characters of each key so you can tell them apart, the creation date, when it was last used and its status.
- You can have up to 10 active keys. Revoking one frees a place.
- Every Tintly tool is read-only, so a leaked key cannot change or delete anything. It can only use up your rate limit.
If a key leaks
- 1Revoke it at once
Open the developer page and press the bin icon next to the key, then confirm. A revoked key stops working within a minute.
- 2Create a replacement
Make a new key with a clear name and put it where the old one was, through an environment variable.
- 3Find how it leaked
Check commits, logs, chat history and screenshots. If it was in a public repository, assume it was copied and rotate any other secret that sat beside it.
- 4Clean the history if needed
Removing the key from the latest commit is not enough, because it is still in the history. Revoking is what actually protects you.
Rotating a key without downtime
Rotation is just creating, swapping and revoking, in that order. Because you can hold up to 10 active keys, there is room for the old and the new key to work side by side. Create the new key, deploy it wherever the old one lived, check that the old key shows no new use in its last used column, and only then revoke it. Done this way, a rotation is a non-event, and doing it every few months stops being something you put off.
Storing keys in common places
| Where | Good practice |
|---|---|
| Your shell | Export TINTLY_API_KEY in a profile file that is not shared or committed |
| A project | Keep it in an untracked .env file and list that file in .gitignore |
| CI | Use the CI system's encrypted secrets, never plain variables in the workflow file |
| An editor or assistant | Prefer its input prompt or environment variable support over a literal key in a shared config |
None of this is specific to Tintly, and all of it takes minutes. The reward is that the day a key does leak, it is a one-click fix instead of an incident.