Developers · DevOps · AI agents
Share API keys securely.
Read once, then gone.
Stop pasting keys in Slack. Create a single-use encrypted link — the key self-destructs the moment it's read. No trace in message history, no server-side copy.
No account required to send. Works in any browser or terminal.
Where leaked API keys come from
Most API key breaches don't come from sophisticated attacks — they come from the same three places every team uses to share them.
Slack / Teams
Every API key sent over Slack lives in message history indefinitely. Workspace admins, third-party integrations, and data export requests can all surface it. A single account compromise exposes every key ever shared.
Lives in sent folder, inbox, and every device both parties sync to. Email breach, phishing, or a forwarded thread can expose keys shared months or years ago.
Git repositories
The most common leak vector. A key accidentally committed — even once, then removed — is permanently in git history. Public repo exposure triggers automated scanners that abuse keys within minutes.
.env files shared via cloud storage
A .env file in Dropbox, Drive, or a shared folder stays accessible indefinitely. One misconfigured permission and every key in it is exposed.
The right way: encrypted, single-use, self-destructing
A VoidNote link is a sealed envelope that incinerates after it's opened. The key exists in transit for seconds. Once read, there's nothing left to leak.
- 1
Paste the key — or pipe it from your terminal
Use the web UI or CLI. Put one key or a whole bundle of env vars in a single note. You control the view count (1 for handoff, more for small teams).
- 2
AES-256-GCM in the browser — server never sees the key
Encryption runs locally. The decryption key embeds in the URL fragment — never in a request, never in a log. VoidNote's infrastructure holds only ciphertext it cannot decrypt.
- 3
Recipient reads it — note self-destructs
The developer, agent, or pipeline fetches the note. Their browser or SDK decrypts the key locally. The server deletes the record. The link is dead. The key existed on our infrastructure for seconds.
CLI & SDK workflow
Integrate secure key delivery into any shell script, CI pipeline, or automated workflow.
# Single key
echo "sk_live_abc123…" | voidnote create --views 1 --quiet
https://voidnote.net/note/a1b2c3…
# Multiple env vars
printf 'STRIPE_KEY=sk_live_…\nDB_URL=postgres://…' | voidnote create --views 1 --quiet
https://voidnote.net/note/d4e5f6…
# Read directly into a shell variable
export STRIPE_KEY=$(voidnote read https://voidnote.net/note/a1b2c3…)
# Or load as env vars (newline-separated key=value)
eval $(voidnote read https://voidnote.net/note/d4e5f6… | sed 's/^/export /')
# note self-destructed — link is now dead
Delivering secrets to AI coding agents
Paste a VoidNote link into your CLAUDE.md, system prompt, or task file. The agent reads it via the CLI or SDK, loads the keys into memory, and the note self-destructs. No key ever touches a commit, a config file, or a conversation log.
Full guide: giving Claude Code secrets without exposing them →What developers share via VoidNote
Stripe / payment keys
sk_live_ keys for production payment processing — the most sensitive key most teams handle.
Database credentials
Production connection strings including host, port, user, password, and database name.
Cloud provider keys
AWS access keys, GCP service account JSON, Azure client secrets, Cloudflare API tokens.
GitHub / GitLab tokens
Personal access tokens, deploy keys, and CI tokens for pipeline bootstrapping.
Third-party API keys
OpenAI, Resend, Twilio, SendGrid, Mailchimp — any key that grants access to a paid or sensitive service.
SSH private keys
Server access credentials for onboarding contractors or provisioning automated deployments.
Questions
What if the recipient's network connection drops while reading the note?
The note is consumed atomically when the request completes. If the connection drops before the note is fully delivered, the server treats it as an incomplete read and the note remains available. The record is only deleted on a successful complete response.
Should I rotate the key after sharing it via VoidNote?
For high-sensitivity production keys, yes — share a short-lived or scoped key when possible, then rotate it after use. VoidNote guarantees the key isn't lingering on any chat platform, but it's still good practice to use short-lived credentials where your provider supports it.
Is there an audit trail of who accessed the note?
No — by design. Once consumed, the record is deleted. There is no log of the access, no stored metadata about the recipient, and no way to recover what was in the note. This is the zero-knowledge guarantee: nothing to subpoena, nothing to breach.
How is this different from a secrets manager?
Secrets managers (Vault, AWS Secrets Manager, Doppler) are for long-lived credential storage and application runtime access. VoidNote is for secure one-shot delivery — getting a key from person A to person B or system B without leaving a copy anywhere. They're complementary: use a secrets manager for production, use VoidNote to deliver the initial credentials to bootstrap it.
Share your next API key the right way
Takes 10 seconds. Works in browser and terminal. No trace left anywhere.