How to Securely Share Test API Keys With Contractors

A test key can escape through a chat message, a build log, or a file that gets committed by mistake. The safer approach is to give contractors access to a dedicated test credential through a controlled secrets workflow, then end that access when the work is done.

Keep the key out of source code, limit what it can do, and track who can access it. EnvManager can help manage encrypted environment secrets and control access by role.

Step 1: Create a dedicated test key with limited permissions

Start with a new credential for this contractor and this test environment. Don’t reuse a production key or a shared team key. A separate credential makes it easier to limit access and tell which work caused a suspicious request.

Generate the key in the API provider’s dashboard or approved workflow. Give it a name that makes its owner and purpose clear, such as contractor-checkout-staging. Record the service, environment, owner, creation date, planned end date, and the person who can revoke it.

Set the smallest scope the test needs. If the contractor is checking a read-only endpoint, don’t grant write access. If the provider supports limits by endpoint, project, IP address, or usage quota, apply the restrictions that fit the test. Test the key against the intended request before you send it.

API keys identify an application or caller, but they aren’t a substitute for a person’s login. Give the contractor an individual account or access identity where your systems support it, rather than sharing an employee’s credentials.

Keep test and production credentials in separate projects or environments. That separation reduces the chance that a routine test can touch live data or services. EnvManager uses role-based permissions, so you can keep access tied to a person’s role and the right environment.

For a broader checklist on key scope, storage, and monitoring, use EnvManager’s API key security best practices as you set up the credential.

Milestone: You should have one named test key with only the permissions this contractor needs.

Step 2: Grant individual access through an encrypted secrets workflow

Give the contractor a secure way to retrieve the secret without placing it in a ticket, email thread, or team chat. The best routine is to grant access through a secrets manager. The contractor signs in with their own account, and the system checks their permission before revealing or syncing the value.

Store the key in the correct project and environment. Assign access to the contractor’s individual account, not a broad group unless every group member needs the same secret. Set read access if they only need to run tests. Reserve edit or admin rights for the people who manage the credential.

EnvManager encrypts values with AES-256 via Supabase Vault. Its role-based permissions help separate access by person or role, and its immutable audit trail records reads, writes, and access attempts. Teams can also sync secrets to supported development and CI/CD workflows rather than copying values into a repository.

If a contractor needs a one-time handoff, use an encrypted link that expires after it’s viewed. EnvManager’s one-time encrypted secret links are designed for sending a key without leaving its value in a message history. Send the link through a separate channel from any passphrase you use.

Before sharing, check what the recipient will see. Avoid link previews or automated scanners that might open a one-time link before the contractor does. Tell the contractor when to expect it, ask them to confirm receipt, and don’t paste the key itself into the confirmation message.

For a short engagement, a one-time link can cover delivery. For ongoing work, individual vault access is easier to audit and remove. Either way, the goal is to share controlled access, not leave a reusable key in a place others can search later.

Milestone: The contractor can retrieve the test secret through an approved path tied to their own identity.

Step 3: Help the contractor configure the key without exposing it

Once access is in place, help the contractor connect the key to their test app without putting it in code. Ask them to store it as an environment variable or retrieve it from the secrets manager at run time. The app can read the value while the source files stay free of credentials.

For local work, keep the secret in a local environment file that is excluded from version control, or use the team’s approved secret-sync workflow. Check that the project’s ignore rules cover local secret files. A safe example can show the variable name without the value:

TEST_API_KEY=replace-with-secret-from-approved-store

That placeholder is only a label. Don’t commit a real value, even briefly. Don’t put keys in screenshots, pull-request descriptions, issue comments, sample config files, or shell commands that may be saved in history.

For CI, inject the value through an approved secret store or pipeline secret setting. Mask it in build output, and make sure scripts don’t print environment variables during debugging. If the contractor needs to test from a browser app, don’t put a private key in client-side JavaScript. Route the request through a server-side service that can keep the key private.

When a workflow uses a bearer token, protect it in transit and keep it out of logs and code.

Agree on a simple test: the contractor runs one allowed request, then checks that a request outside the key’s scope is denied. Review the application output together without asking them to paste the secret into chat. If a test fails, troubleshoot the variable name, environment, or permission first.

Milestone: The test app reads the secret from its environment or secret store, and no real value appears in source control or logs.

Step 4: Set an expiration, rotation plan, and access review

Give access an end date before the contractor starts. If the API provider supports key expiration, set it to match the engagement. If it doesn’t, add a calendar reminder or ticket for the person who owns the key. Don’t rely on someone remembering an informal promise to remove access later.

Keep a short record of what the key protects and where it is used. Note whether the contractor has access through a local setup, a CI job, or both. That map will help you replace the key without missing a test runner or deployment setting.

Plan rotation around the provider’s controls and the project’s risk. If the work continues past the planned date, issue a replacement before the old key expires. Update the approved secret store, test a request with the new key, then disable the old one. If the provider doesn’t allow an overlap, plan a brief test window so the change doesn’t surprise the team.

Review access during the engagement, especially when the task changes. A contractor who began with read-only test access shouldn’t keep broader permissions after the work shifts. Check the audit trail for access that doesn’t match the schedule or agreed task. EnvManager logs secret access attempts, which can help you investigate a question without putting values in the review notes.

Use the review to confirm the owner, scope, end date, and delivery path are still accurate. For work tied to a customer contract or security framework, map your process to the specific contract requirements and have your security or legal team review any commitments. Don’t assume one checklist fits every engagement.

Milestone: A named owner knows when access expires and how to rotate the key without leaving a forgotten copy in a pipeline.

Step 5: Revoke access and verify cleanup when the work ends

Close access as part of the project handoff, not as a later cleanup task. Remove the contractor from the relevant project or secret store, then revoke or disable the test key at its provider if it’s no longer needed. If the key was exposed, revoke it right away rather than waiting for the contract to end.

Check every place the credential could have gone. Review the secret manager, CI settings, local setup instructions, test runners, and any temporary proxy or gateway configuration. Ask the contractor to remove local copies and confirm that they’ve done so, but don’t treat that confirmation as a replacement for revoking the credential.

Then verify that the old key no longer works. Send a test request with it and confirm the provider rejects the request. Run a valid request with the replacement credential, if the project still needs one. This checks both sides of the change: the old access is closed, and the active test path still works.

Look at the audit trail for access after the planned end date. If you find an unexplained read or failed request, preserve the relevant event details and follow your incident process. Don’t copy the secret into the incident record. Log who owned the response and what access was disabled.

Teams that still send credentials in chat can reduce that risk by changing the handoff itself. EnvManager’s guidance on how to stop sharing secrets in Slack describes a permission-based approach instead of posting values into message history.

For a short contractor playbook, write down the key owner, approved use, expiry date, and revocation contact. Add a final check for repository history and build logs if anyone may have pasted the value during the project. If the key reached source control, rotate it first; deleting a line does not invalidate a credential.

Milestone: Access is removed, the old key fails, and the project owner has checked the places where it was used.

FAQ

Is it safe to send an API key over Slack?

It’s safer not to send a test API key through Slack because message history can remain searchable after the handoff. Use individual access in a secret manager when possible. For a one-time transfer, use an encrypted link that expires after viewing, then store the key in the approved secret workflow.

Should a contractor use a production API key for testing?

No, give a contractor a separate test key whenever the provider supports one. Limit its permissions to the test task and keep it in a distinct environment from production. That way, a test request or accidental leak is less likely to reach live services or data.

How do I keep an API key out of a contractor’s code?

Store the key outside the source tree and pass it to the app as an environment variable or through a secret manager at run time. Check that local secret files are ignored by version control. For CI, use protected secret injection and confirm build scripts don’t print values to logs.

When should I revoke a contractor’s test API key?

Revoke it when the assigned work ends, when access is no longer needed, or as soon as exposure is suspected. Remove the contractor’s access to the secret store as well. Then test the old credential to confirm it fails, and review logs for use after the agreed end date.

Conclusion

Use a dedicated test key, grant access through an encrypted and auditable workflow, and set the offboarding date before work begins. Start with one contractor project: store its test secret in EnvManager, assign only the access that task needs, then verify revocation when the engagement ends.