Share an API key with a contractor without putting it in email

You hire a freelancer to build a feature that calls the Stripe API. They need the secret key. What do you do? Drop it in a Slack DM where it sits in the message history forever. Email it from your personal account. Paste it into a shared Notion page that has 14 viewers. None of these is great.

The problem is not really about Stripe or about the contractor. It's about handing off a secret to someone for a finite period of time, in a way you can revoke later, without leaving a copy of the cleartext value in three different chat logs.

SaltingIO has a feature aimed at exactly this. It's not the headline use case (most marketing copy focuses on hiding a key behind a frontend Bridge), but it solves the human side of credential sharing cleanly.

Why "just paste it in 1Password" doesn't quite work

Shared vaults are the right answer for ongoing access inside your own team. They start to feel awkward when the person on the other end is not a permanent team member: a contractor finishing a two-week project, an agency working on a specific integration, a client you're handing a deliverable to.

The friction looks like this. You provision a 1Password account for them, you wait for them to install the app, you set up the shared vault, you grant access, you wait for them to confirm, and at the end of the engagement you remember (or forget) to revoke. If they never log in again, the shared vault membership often quietly persists.

Email or chat is faster but leaves cleartext in a searchable archive on a system you don't control. Disposable paste services solve the cleartext-in-archive problem, but you lose any audit signal: who opened it, when, and from where.

The pattern: a password-protected page on salting.io

Inside the SaltingIO dashboard, when you create a Credential set to Private access, there's a checkbox labeled "Enable Secure Page" with a password field. Check it, set a password, and the credential becomes accessible at a public URL:

https://salting.io/secure/{uuid}

The page itself prompts for the password and only reveals the credential after the prompt is satisfied. The URL alone is useless without the password. Send the link in Slack, and send the password through a different channel: SMS, a voice call, a separate email, anything. An attacker would need both.

The credential is encrypted at rest with AES-256-GCM. The password gates the decryption, and SaltingIO does not store it in cleartext, so a database read does not expose the underlying secret. If the contractor never opens the link, no decryption happens at all.

When the contractor needs programmatic access, not a UI page

The secure page is a human-facing flow. It's good for "here's the key, please paste it into your own dev environment." If the contractor's code needs to fetch the key at runtime (for example, a CI job they own that talks to your Stripe account), the right pattern is different: give them a private Credential record with an X-API-Key, and have their code fetch it on demand.

curl -H "X-API-Key: $SALTING_KEY" \
  https://api.salting.io/r/9f2c1d7e-4b8a-4c3f-9e2d-1a6b8c4d5e7f
# {"data":"sk_live_..."}

A few things matter here.

The X-API-Key is shown exactly once, on the success modal that appears right after the credential is created. There's a Download .txt button next to it. Close the modal without saving the key and you cannot retrieve it later, you have to rotate the credential. State this in your handoff doc so the contractor copies it immediately.

The auth header is X-API-Key, not Authorization: Bearer. Bearer tokens on api.salting.io are dashboard JWTs for the SaltingIO web app itself, not the per-record access keys.

Use a Private record, not a Public one. Public records skip the X-API-Key check entirely, which is the right choice for a Bridge that you've already locked down with an Origin allowlist for browser traffic, but the wrong choice for handing access to one specific person.

Revoking access at the end of the engagement

The reason this is better than 1Password for short-term collaborators is what happens at the end. Two options, depending on what you handed out.

If you used the password-protected secure page, rotate the password on the existing credential. Open the credential in the dashboard, change the password field, save. Any old link the contractor still has becomes useless because the password they have no longer decrypts it. If they have already copied the underlying value (which is the realistic assumption: anyone who needs a credential will save it locally), rotating the password does nothing about that copy. Rotate the actual upstream secret at Stripe or OpenAI when the engagement ends. The SaltingIO record is a transport layer, not a retroactive seal.

If you used the X-API-Key pattern, rotate the X-API-Key from the dashboard. The old key stops working immediately, the new one is shown once on the rotation modal, and any code the contractor wrote that pointed at the same UUID will fail with a 401 until you reissue:

{"error":"Authentication required",
 "message":"Please provide your token in the X-API-Key header to decrypt the content."}

Common pitfalls

The same UUID in /secure/ and /r/. A Credential record has one UUID, and that UUID appears in both the human-facing secure page URL and the programmatic /r/ endpoint. If you're using the secure page for a person, do not also hand the same UUID to that person's code with X-API-Key access. Revoking one route does not close the other, and you have to remember both exist. Create two separate records, one for human handoff, one for code, and rotate them independently.

Sharing the password over the same channel as the link. The whole security model rests on the password and the link traveling separately. Slack thread with the link, voice memo with the password is fine. Slack thread with both is just a paste site with extra steps. If the contractor screenshots both into the same Notion page, the policy you wrote is now a fiction.

Forgetting that the underlying upstream key is the real secret. The SaltingIO record is a wrapper around your Stripe or OpenAI key. Rotating the SaltingIO password or X-API-Key does not rotate the upstream value. After the engagement ends, rotate the upstream key at the provider too. Both are cheap. Doing only one is the audit-finding version of locking the front door and leaving the back open.

Handing a secret to a one-off collaborator is one of those problems that quietly accumulates risk because every individual instance feels small. A password-protected link plus an out-of-band password covers the human side, and an X-API-Key on a private record covers the machine side. Neither requires you to provision a new account in your password manager for someone who will be gone in three weeks.

Start building