How to send API keys securely

Send the key as a one-time link that's destroyed when the recipient opens it, not as a message in Slack or a ticket. If they need it again, rotate the key and send a new link.

API keys leak differently from passwords. Nobody memorises one, so it gets pasted somewhere to be found again later — and "somewhere to find it later" is the whole problem.

Why the obvious approaches fail

Slack and Teams. The default, and the worst one, because it feels ephemeral and isn't. Chat is indexed and searchable by design, exports include everything, and a channel's history is visible to whoever joins next. A key pasted into #engineering in 2024 is readable by the contractor who joins in 2026. Deleting the message does not reliably remove it from exports, from someone's phone notification, or from an integration that already ingested it.

Tickets. Worse in one specific way: tickets are deliberately retained, often exported into reporting tools, and frequently readable by more people than the channel would have been. A credential in a Jira comment is a credential in a data warehouse.

A .env file over email or a shared drive. Now the key has a filename, which makes it findable, and it will be sitting in a downloads folder on a laptop somewhere for years. Attaching it to email adds every mail server on the path.

Committing it "temporarily". Git does not forget. Rewriting history doesn't help once the commit has been pushed and pulled, and public repositories are scraped for keys within minutes. If this has happened, rotation is the only fix.

The realistic options

A secrets manager

HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Doppler and similar.

Choose this if the consumer is a running service. It's the right answer for distribution to machines: rotation, versioning, access policies and audit are all built in. It's a poor fit for handing one key to a person who needs it once, because you have to give them access to the manager first — which is a bigger grant than the key was.

Your password manager

1Password, Bitwarden and others store API keys as items and can share them.

Choose this if the recipient is on your team and already uses it. For a contractor or a client's developer who doesn't, you're asking them to adopt a tool to receive one string.

A free one-time secret tool

Paste the key, get a link, the link works once.

Choose this if you hand over keys occasionally and don't need a record of who opened what. It's a solid answer and costs nothing.

A dedicated one-time sharing service

The same mechanic, plus the things a team needs when this is routine: your own domain on the link, attachments for the config file that goes with the key, an audit trail, and an API so provisioning can be scripted rather than remembered.

Where SecretWolf fits — and where it doesn't

A key goes as a one-time encrypted link, destroyed on first view. You can attach the .env or certificate that goes with it — malware-scanned, encrypted at rest, and deleted on the same rules. The audit trail records which developer opened which key and when, which is the part that matters when someone later asks how a contractor got access. Because there's an API, key handover can be a step in your provisioning script rather than a thing someone remembers to do properly.

For agent-driven workflows there's a machine-payable endpoint too: an AI agent can create a one-time link and pay per call with no account, and hand the link to a human — or to another agent, which consumes it over JSON exactly once. That's covered on the AI agents page.

Where it doesn't fit. It is not a secrets manager. If your problem is a fleet of services that need to fetch credentials at runtime, use Vault or your cloud's equivalent — SecretWolf handles the human handover at the edge of that system, not the system itself. It also isn't zero-knowledge: encryption is server-side, so if no server may hold the key, a self-hosted browser-side tool is the honest recommendation.

In context: sending API keys and how MSPs hand over credentials.

Questions people ask

How should I send an API key to a developer?

As a one-time link that's destroyed when they open it, so the key doesn't stay in a chat channel or a ticket. If they need it again, rotate the key and send a new link — resending the old one just creates a second copy.

What's wrong with pasting a key in Slack?

It stays in message history, search and exports indefinitely, and everyone added to the channel later can read it. Deleting the message doesn't reliably remove it from exports or from a notification someone already received.

Should I use environment variables instead?

For a running application, yes — but that's a different problem. Env vars solve where a key lives at runtime; this is about how it gets to the person who sets them. You still have to hand the value over once.

What if I send a key to the wrong person?

Revoke the link if it hasn't been opened, then rotate the key regardless. Rotation is the only action that actually closes the exposure — the link is what tells you whether you needed to hurry.

Do I need a secrets manager for this?

If you're distributing keys to running services, yes — Vault, AWS Secrets Manager or your cloud's equivalent. They're built for machines fetching secrets, not for handing one to a contractor who'll paste it into their local .env once.