The API Key Problem
API keys are the passwords of the developer world. They grant access to databases, cloud infrastructure, payment systems, and third-party services. A leaked API key can cost real money — from unexpected cloud bills to exposed customer data.
Yet most teams share them the same way they share everything else: copy-paste into a chat message. The key ends up stored permanently in a Slack workspace, an email archive, or a Confluence page that half the company can access.
Real cost: Exposed AWS keys are routinely exploited within minutes of being published. Automated bots scan public repositories and paste sites for key patterns. A single leaked key can generate thousands of dollars in unauthorized cloud usage within hours.
Common Mistakes When Sharing API Keys
- Slack or Teams messages — Stored forever in workspace history, searchable by admins and compliance tools.
- Git commits — Even if you delete the key in a later commit, it remains in git history forever unless you rewrite the entire branch.
- .env files in shared drives — No access controls, no audit trail, often shared with the entire team.
- Confluence or Notion pages — Wikis are designed for sharing, not secrets. Anyone with workspace access can find them.
- GitHub issues or PRs — Public by default on open source projects. Even on private repos, all collaborators can see them.
The Right Way to Share API Keys
There are three tiers of solutions, depending on your team size and infrastructure maturity.
Tier 1: One-Time Links (Quick and Secure)
For ad-hoc sharing — onboarding a new developer, giving a contractor access, sharing a key with a teammate who needs it right now — one-time links are the fastest secure option.
- Paste the API key into onetimelink.me.
- Set a short expiration (5-15 minutes is usually plenty).
- Send the link to your teammate via any channel.
- The key is destroyed after they view it. Nothing persists.
The key is encrypted in your browser with AES-GCM before being sent to the server. The server never sees the plaintext key. The decryption key exists only in the URL fragment, which browsers never send to servers.
Tier 2: Secrets Managers (Automated and Scalable)
For production infrastructure, use a dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or Doppler. These tools:
- Inject secrets directly into applications at runtime.
- Provide audit logs of who accessed what and when.
- Support automatic key rotation.
- Eliminate the need for humans to ever see or type the key.
Tier 3: Environment-Specific Configuration
For development environments, use .env files that are gitignored and never committed. Share the initial values via one-time links, then each developer manages their own local copy.
Best Practices for API Key Security
- Use the principle of least privilege. Give each key only the permissions it needs. Never share a root or admin key when a scoped key would work.
- Rotate keys regularly. Set a rotation schedule and stick to it. At minimum, rotate keys when someone leaves the team.
- Use separate keys per environment. Development, staging, and production should never share the same keys.
- Monitor for leaks. Use tools like GitGuardian or GitHub secret scanning to detect accidentally committed credentials.
- Set expiration dates. Where possible, use short-lived tokens or keys with built-in expiration.
Quick rule: If an API key is important enough to keep secret, it is important enough to share securely. The 10 seconds it takes to create an encrypted link is always worth it.
Share API keys without the risk
Encrypted in your browser, destroyed after one view. The server never sees your key.
Create a secure link