A one-time secret link is a URL that reveals a piece of sensitive text, such as a password or API key, once and then stops working. It keeps the secret out of chat and email history and reveals when someone else opened it first, but it cannot stop the recipient copying it or protect a compromised device.
Key takeaways
- A one-time link moves a secret once and leaves only a dead URL in your chat or email history.
- If the recipient finds the link already used, treat the secret as exposed and change it.
- It does nothing about screenshots, copy-paste, clipboard history or malware on either device.
- Link previews and email scanners can open links automatically, so test your channel and add a passcode for anything important.
- Use one-time links for one-off handoffs. Use a password manager for credentials a team shares every day.
What is a one-time secret link?
A one-time secret link is a URL that points to a stored secret rather than containing the secret itself. You paste a password, an API key or a door code into a service, it gives you a link, and you send that link instead of the raw text.
When the recipient opens it, they see the secret. After that, or after a time limit, the note is destroyed and the link returns nothing. That is why people also call it a single use link or a one time link for sensitive information.
The point is simple. Whatever channel carried the link (Slack, email, SMS) ends up holding a dead URL rather than a live credential. Six months from now, someone searching your chat history for "password" finds nothing useful.
What does a one-time link actually guarantee?
Strip away the marketing and a well-built one-time link gives you three real guarantees.
The secret stops living in the channel
Your message history, email archive and their backups hold a link that no longer works. That matters more than most people expect, because chat and email get synced to phones, laptops, search indexes and admin exports.
You shrink the number of places a secret lives from "everywhere the message went" to "one place, briefly".
You find out if someone got there first
If an attacker or a curious colleague opens the link before your recipient, the recipient finds a dead link. That is a signal. It tells you the secret may be exposed and needs changing.
A password pasted into an email gives you no such warning. You would never know a forwarded copy was read.
The stored copy has a deadline
Even if nobody opens it, the note does not sit around forever. With SecureNotes, each note is encrypted with AES-256 using its own random key before it is stored. You choose when it is destroyed: after 1, 3, 5 or 10 views, after 1 hour, 24 hours, 7 days or 30 days, or whichever comes first.
What a single use link does not protect against
This is where people overestimate the tool. A one-time link controls delivery. It does nothing about what happens on either end.
- The recipient copying it. Once the secret is on screen, they can paste it into a notes app, a spreadsheet or a team channel. They can screenshot it. The link self-destructs; their copy does not.
- The sender's device. If you drafted the password in a text file, or your clipboard manager keeps history, or your laptop has malware, the secret leaked before the link existed.
- The recipient's device. A compromised phone or a shared family computer exposes the secret at the moment it is read.
- The wrong person opening it first. Anyone holding the URL can open it. The one-time property tells you after the fact; it does not prevent it. A passcode sent through a different channel closes most of that gap.
- Identity. The link does not prove who sent it or who received it. If an attacker spoofs your email address, they can send their own "secure link" too.
- The secret's validity. Destroying the note does not change the password. If the credential still works, whoever read it can still use it.
If human slips are the bigger risk on your team, this piece on designing secret-sharing workflows that survive human error goes deeper.
Can link previews and email scanners burn the link?
This is the failure technical readers ask about most, and it is real. Many chat apps fetch a URL to build a preview card. Many corporate email gateways open links to scan them for malware before the message reaches the inbox.
Whether an automated fetch counts as a view depends on how the service is built. If a bot triggers the reveal, a single-view note could be used up before a human ever sees it, and your recipient gets a dead link for no sinister reason.
Practical ways to handle it:
- Test once. Send yourself a throwaway note through the same channel your recipient uses (Slack, Outlook, iMessage) and check the link still opens.
- Loosen the view count slightly. If the recipient's company scans links aggressively, set 3 views with a 1-hour limit instead of a single view. You trade a little strictness for reliability.
- Add a passcode. The note does not open until someone enters it, and an automated scanner does not have it.
- Turn on the read notification. You get an email when the note is read, which you can compare with when your recipient says they opened it.
When should you use a one time link for sensitive information?
One-time links fit secrets that need to move once, from one person to another, and then live somewhere else or nowhere at all.
- A landlord texting a guest the lockbox code for a weekend stay, set to expire after 7 days.
- A developer sending a new hire a staging API key on day one, before they have access to the team vault.
- An IT admin giving a user a temporary password that must be changed at first login. This is the classic one-time password link.
- Moving two-factor recovery codes to a trusted family member who would need them in an emergency.
- A contractor who needs the Wi-Fi password and alarm code for a single site visit.
- A database connection string pasted into a support ticket that would otherwise be archived for years.
It is the wrong tool in a few common cases. Credentials a team uses every day belong in a password manager with proper access control. Payments belong in your bank's or invoicing tool's own flow. Confirming who someone is belongs on a phone call to a number you already have. For the longer comparison, see when one-time links or password vaults make sense.
How to send a one-time secret link the safe way
- Put the secret straight into the note. Go to SecureNotes and create a self-destructing note. Paste or type the text there, not into a draft email or doc first. Notes hold up to 10,000 characters of text; there are no file attachments.
- Choose when it self-destructs. For most handoffs, pick 1 view or 24 hours, whichever comes first. If link scanners are in the way, use 3 views and 1 hour.
- Add a passcode for anything that matters. Production credentials, recovery codes and admin passwords all qualify. Use something short but not guessable from the message.
- Turn on the read notification. You will know when the note was opened without having to ask.
- Send the link. Paste it into chat or email yourself, or let SecureNotes email it to the recipient.
- Send the passcode another way. If the link went by email, send the passcode by text message or read it out on a call. This guide on sending the passcode safely covers which pairings work.
- Confirm receipt, then rotate if needed. Ask the recipient to confirm they got it. If they report a dead link they did not open, assume exposure and change the secret.
If you hand out secrets from scripts, such as onboarding automation or a deployment pipeline, the SecureNotes REST API creates the same kind of note programmatically.
One-time link vs other ways to share a secret
| Method | What stays in history | Warns you about interception | Recipient can still copy | Best for |
|---|---|---|---|---|
| Plain chat or email | The secret, indefinitely | No | Yes | Nothing sensitive |
| One-time link | A dead URL | Yes, the recipient finds it already used | Yes | One-off handoffs |
| One-time link plus passcode sent separately | A dead URL | Yes, and the link alone is not enough | Yes | Credentials, recovery codes, high-value secrets |
| Password manager sharing | The secret, inside an access-controlled vault | Depends on the tool | Yes | Credentials a team uses repeatedly |
| Phone call | No written record | You hear who answers | Yes, they write it down | Short codes, verifying payment details |
Notice the "Recipient can still copy" column never changes. No sharing method fixes that. Trust in the recipient and rotation afterwards are what handle it.
Common mistakes that undo a one-time link
- Sending the passcode in the same message as the link. Anyone who sees the message now has both halves. Split them across channels.
- Picking a 30-day expiry for something needed today. A long window gives an intercepted link more time to be used. Match the expiry to the actual handoff.
- Resending without asking why. "It says expired, can you send it again?" is the moment to check whether you should rotate the secret, not just to resend it.
- Labelling the message. "Prod database root password:" followed by a link tells anyone who sees it exactly what is behind it. Keep the surrounding text bland.
- Treating the link as storage. The recipient needs a proper place to keep the secret afterwards, ideally their own password manager, not a sticky note or a pinned chat message.
- Never rotating. Temporary passwords should change at first login, and contractor credentials when the work ends. The OWASP Secrets Management Cheat Sheet covers rotation in more depth.
- Trusting an unexpected link. Phishers imitate secure-note emails. If you did not expect one, confirm with the sender through a different channel before you type anything into it.
Frequently asked questions
Is a one-time password link the same as a one-time password (OTP)?
No. A one-time password is a short code, usually from an authenticator app or SMS, that logs you in once. A one-time password link is a way to deliver any password, including a permanent one, through a URL that works once. The link limits how the password travels; it does not make the password itself expire. You still need to change it if it should not stay valid.
What happens if the recipient never opens the one-time link?
The note expires at the time limit you chose, such as 1 hour, 24 hours, 7 days or 30 days, and the link stops working. Nobody can open it after that, including the intended recipient. If they still need the secret, create a fresh note rather than reusing old text from somewhere else, and consider a shorter expiry if the first one was missed through delay.
Is a one-time secret link safe enough for production credentials?
It is much safer than pasting credentials into chat or email, as long as you add a passcode and send that passcode through a separate channel. For production access that several people use regularly, a one-time link is best for the initial handoff only. Long-term storage and shared access belong in a password manager or secrets manager with proper permissions and audit history.
Do I need an account to create a one-time link on SecureNotes?
No. SecureNotes is free and needs no account or sign-up. You paste your text, choose when it self-destructs, optionally add a passcode and a read notification, and get a link to send. Developers can also create notes from scripts and tools through the free public REST API, which is documented on the SecureNotes site.
Can a one-time link be opened more than once?
Only if the sender allows it. On SecureNotes you choose 1, 3, 5 or 10 views, a time limit, or whichever comes first. A single-view note works once and then the link is dead. A higher view count is useful when you expect email scanners or link previews to open the URL, or when a small group legitimately needs to read the same note.
