API Key Sharing Checklist for Contractors

Contractors and vendors often need access to your systems for a few weeks. If you hand over an all-powerful production key in a message, you create a risk that outlasts the project. This API key sharing checklist keeps the access small and short-lived.

Before you create the key

• Decide exactly what the contractor needs to do.
• Check whether the service supports scoped or read-only keys.
• Use a sandbox or staging key if production is not required.

Create the key

1. Create a new key just for this contractor, never a shared team key.
2. Name it clearly, for example “vendor-name-project-2026”.
3. Give it the smallest set of permissions that works.
4. Set an expiry date if the service supports one.

Share it safely

1. Put the key in a one-time link with a short expiry.
2. Send the link to the one person who needs it, not to a group.
3. If you add a passphrase, send it by another channel.
4. Ask the contractor to store the key in a secrets manager or environment variable, not in code or documents.

While the work runs

• Watch the key’s usage for unusual activity or unexpected locations.
• Do not extend access without a reason.
• Keep a record of who has which key.

When the work ends

• Revoke the key the day the project finishes.
• Check that nothing in your systems still depends on it.
• If the key was ever seen outside the agreed channel, treat it as compromised and rotate it.

Scoping examples

• A designer who needs to see analytics: a read-only viewer role, not an owner.
• A developer fixing a bug in staging: a staging-only key, not production.
• An integration partner: a key restricted to the specific endpoints it calls.
• A short audit: a key that expires at the end of the audit window.

A message to send with the link

“Here is a one-time link to the API key for [project]. It works once and expires in [time], so please save it straight away in your secrets manager. It is scoped to [permissions] and will be revoked on [date]. Do not paste it into code, tickets or chat. If anything looks wrong, tell us and we will rotate it.”

Mistakes to avoid

• Reusing the same key for several contractors, so you cannot tell who used it.
• Committing a key to a repository, even a private one.
• Leaving a key active “just in case” after the project ends.
• Sending the key and instructions that reveal how to use it in the same chat thread as other secrets.

Frequently asked questions

How long should a contractor’s API key last?

As short as the work allows. Set an expiry date if the service supports it, and revoke the key the day the project ends.

Is it safe to send an API key in a chat message?

It is better avoided, because the message stays in the chat history. A one-time link leaves nothing to find later.

What should I do if a key was exposed?

Rotate it immediately, update the systems that use it, and review the key’s usage logs for anything unexpected.

A safer way to share secrets

Hand over the key without leaving a copy behind. How to send API keys securely. By default, SecureVoult shows a secret once and then deletes it, so nothing is left behind in email, chat or tickets.

Keep reading:

• Create a one-time secret link