How to share an API key securely, and when to rotate it

The short answer

To share an API key securely:

1. Share less. Give the person their own key where the provider allows it, restricted to what they need, ideally with an expiry date. Use a test or sandbox key if that's all the job needs.
2. Send it as an encrypted link that expires, never as a chat message or email, with a passcode through a second channel.
3. Rotate or revoke it when the job ends, and whenever someone who had it leaves.

On rotation, vendors no longer agree on a fixed calendar. Rotate on events every time (someone leaves, a key was exposed, a vendor finishes), prefer keys that expire on their own, and set a schedule only for long-lived keys you can't avoid.

Who this is for: developers and team leads who hand API keys to teammates, contractors and vendors, and the IT or platform people who issue them.

Why do API keys leak when you share them?

An API key is a password that never asks for a second factor. Whoever holds it is, as far as the API is concerned, you. Keys tend to leak at the moment they are shared:

• Chat and email keep them. A key pasted into Slack, Teams or email stays in message history, search and backups for years.
• They get copied into code. The recipient pastes the key into a script or config file "just to test", and it ends up in a repository. Google's own guidance warns that keys hardcoded in source code or stored in a repository are open to theft.
• One key, many people. When a whole team, a contractor and a CI job share one key, nobody can tell who used it, and revoking it breaks everyone.
• They outlive the job. The contractor finishes, the key keeps working.

What should you do before you share an API key?

The safest key to share is one that can do little, for a short time, for one person.

AWS puts the last point plainly: where possible, rely on temporary credentials rather than long-term access keys.

How do you share an API key securely, step by step?

1. Create a share. In CredenShare, open Shares and click Create Share. Put the key in a Password field, so it is masked until the recipient reveals it, and use a second field for context such as the environment or the allowed scopes.
2. Keep the title generic, for example "Payments API key, staging". Titles and descriptions are stored readable, so the list can show and search them. Only the fields are encrypted in your browser.
3. Set the rules: a short expiry, a view limit of one, and a passcode (Solo and above). If you don't know when they'll open it, set Expire from to First View.
4. Send the link and the passcode through different channels, for example the link by email and the passcode by text message.
5. Confirm it arrived. On paid plans the access log shows when the link was opened and from where, with link scanners labelled. Activity emails, on every plan, can tell you when it's opened.
6. Ask them to store it properly, in their secrets manager or password manager, not in a config file in a repository.

No account? SecurePaste is free with no sign-up. Paste the key, keep Burn after reading on, and add a password. The link expires after 24 hours.

Need a key from someone? When a client or vendor has to send you their API key, send them a Secure Request (Business and Enterprise): a form whose answers are encrypted in their browser, instead of asking them to email it.

How do you share an API key with a contractor or vendor?

Scenario: an agency needs to call your payments API from a staging site for three weeks.

1. Create a restricted key just for them, limited to the endpoints the integration uses, in the test environment if they don't need live data.
2. Put the key in a share with a passcode, an expiry of a few days counted from the first view, and one view.
3. Send the link to your contact by email and the passcode by text message, and check that it was opened.
4. Note in your access register who holds which key and until when.
5. When the project ends, expire or rotate that key. Because it was theirs alone, nothing else breaks. The contractor and vendor access close-out covers the rest of the offboarding.

How often should API keys be rotated?

There is no single number, and the major vendors have moved away from fixed calendars:

Checked on October 28, 2026 against each vendor's documentation (sources below).

What this adds up to in practice:

The 90 days is our suggestion for keys you can't avoid, not a vendor rule. Pick an interval you can actually automate: a schedule nobody follows is worse than event-based rotation done well.

When must you rotate an API key immediately?

• Someone who had the key leaves the team or company.
• A contractor, agency or vendor that had it finishes their work.
• The key appeared somewhere it shouldn't: chat, email, a ticket, a screenshot, a log, a repository.
• A device or account that held the key may be compromised, for example by an infostealer.
• You can't say who has it.

How do you rotate an API key without downtime?

1. Create the new key alongside the old one. Many providers let you keep two keys active at once, and Stripe can rotate a key on a schedule.
2. Deploy it to every place that uses the old key: secrets manager, CI, servers, the people who need it (by an expiring link).
3. Verify that traffic is using the new key. AWS's "last used" information, or your provider's request logs, show whether the old key is still being called.
4. Revoke the old key. Expire or delete it, rather than leaving it "just in case".

What should you do if an API key leaked?

1. Rotate it first. Deleting the message, the commit or the log doesn't help: copies may already exist.
2. Check the provider's logs for use of the leaked key since the exposure.
3. Find out how it leaked, and fix that path: a pasted message, a committed file, a CI log. Our breakdown of the Gheist campaign shows how secrets in CI were read with nothing more than stolen push access.
4. Work through the credential exposure first-actions card.

Summary

• Share less: one restricted key per person or vendor, test keys for test work, expiry where supported.
• Send it as an encrypted link that expires, with a passcode through a second channel.
• Rotate on events every time, prefer keys that expire on their own, and automate a schedule for the long-lived ones you can't avoid.
• When a key leaks, rotate first, then investigate.

Related: How to share .env files with your team securely · The secret zero problem · API Key Generator · All guides

Sources (checked on October 28, 2026):
AWS: Security best practices in IAM ·
Google Cloud: Best practices for managing API keys ·
Stripe: API keys ·
GitHub: Managing your personal access tokens ·
OWASP: Secrets Management Cheat Sheet

Product names are trademarks of their respective owners. CredenShare is not affiliated with them.