API keys: giving an assistant access safely
A key is a password for programs. It deserves the same care and, unlike a password, it is easy to take back.
What it is
A string starting with `tapmy_sk_`, shown once when you create it. The server keeps only a hash, so nobody — including us — can read it back later. Send it as `Authorization: Bearer …` and every request under `/api/` acts as you: pages, images, imports, statistics.
Where it comes from
- You make one: *Account → API keys → Create key*. Name it after the program that will use it.
- An assistant makes one: when it creates a page without your e-mail, the response includes a key for the new account. After you claim, it appears in the same list, marked “created by an assistant”.
What it cannot do
A key cannot mint other keys, revoke keys, delete the account or change its e-mail and password. Those need a browser session — you, logged in. It also cannot see any account but its own. This is the whole point: the worst a leaked key can do is edit your pages, and you can see every edit in the editor and undo it.
Handing it over
- Claude Code: `claude mcp add --transport http tapmy https://tapmy.link/mcp --header "Authorization: Bearer tapmy_sk_…"`.
- A script: put it in an environment variable, never in the code, never in a chat message that will be logged.
- A chat assistant: paste it into the conversation only if the assistant can call the API from there; otherwise it has nowhere to keep it.
When to revoke
When the program that used it is gone, when you are not sure where the key ended up, or when you asked for a one-off build and do not want the assistant on the page any more. Revocation is instant; everything using the key gets “unauthorized” from the next request. Ten keys per account is the limit, so one per program is the sensible habit.