One-time secret sharing for individuals
A free personal account gives you a recipient identity and an encrypted inbox for occasional credential handoffs. You can send up to 12 secrets each calendar year. This is useful for a temporary API key, a short-lived access token or a password that must reach one collaborator without remaining readable in a chat history.
How do I send a secret to another person?
Create your account, complete two-factor authentication and use the send screen to select the supported delivery method. Confirm the recipient ID or destination before submitting. The application encrypts the secret in your browser before sending the payload to the server. Do not add the plaintext value to a separate email explaining that you sent it, since that would recreate the exposure you are trying to avoid.
What does the recipient need?
For account-inbox delivery, the intended recipient signs in to access the message addressed to their recipient identity. For a one-time bearer link, the usable complete link is itself sensitive and may be readable without an account. Do not confuse these delivery modes. Verify the destination with the recipient, and do not forward a bearer link through a group chat or place it in a public issue tracker.
Can I recover a message after reading it?
One-time exchange is intentionally not a password archive. After successful consumption, the exchange cannot be opened again through the application. A recipient who needs a value for ongoing work should store it in an approved password or secrets manager. If the original credential must stop working, revoke or rotate it at the provider that created it; deleting the exchange does not perform that action.
How does the yearly sending limit work?
Each secret you create counts toward the personal account's limit of 12 per calendar year. Received secrets do not reduce your sending allowance. For example, sending three separate temporary tokens counts as three sends, even if they are for the same collaborator. The allowance resets on January 1. A workspace is a separate managed environment for teams, rather than a way to share one personal login among colleagues.
How can I protect my account?
Use a unique account password and keep your authenticator device secure. Confirm the domain before entering login information. Do not send authentication codes or seeds to support. Browser encryption cannot protect against a compromised device that can read the secret before encryption or after decryption. Use a trusted device and follow the issuing service's guidance on key restrictions, expiry and revocation.
What is a sensible example of a personal handoff?
Suppose a collaborator needs to diagnose a problem in a development project. Create a new token limited to that development environment, grant only the permissions the task requires and set an expiry at the issuing provider if it supports one. Confirm the collaborator's identity, then deliver the token through the selected exchange method. After the task, revoke the token at its source and check the provider's activity log. Do not send a production administrator key simply because it is easier to find. This example illustrates a safer process; it does not guarantee that every provider supports the same permission or expiry settings.
How do I get started?
- Register a personal account and choose a unique password.
- Enrol your authenticator and complete the two-factor setup.
- Confirm your collaborator's recipient ID or the intended one-time delivery method.
- Send a narrowly scoped secret and confirm receipt through a separate, trusted conversation.
Definitions and further reading
- Ciphertext
- The encrypted form of a message, rather than its readable plaintext.
- Credential rotation
- Replacing an existing password or token, and revoking the old value at its issuing service.
- One-time exchange
- A delivery mechanism that removes application access after consumption, not a guarantee against copying on the recipient's device.
These independent references explain the underlying concepts. They are not endorsements, certifications or an independent audit of API Key Pro.
- NIST: the Advanced Encryption Standard (FIPS 197)
- MDN: Web Crypto encryption and AES-GCM
- MDN: how URL fragments work
- OWASP: secrets management, rotation and revocation
Read our privacy policy and terms of service, or contact the team about a specific requirement.