Before you paste a production credential into anything, you should know exactly where it goes and when it stops existing. This page is that answer.
When a link is created, each secret is encrypted with AES-256-GCM. The encryption key is derived from the link's token, and the server stores only a SHA-256 hash of that token, never the token itself.
That means a copy of the database, on its own, cannot reveal a secret. Decryption happens only when someone presents the actual link.
The secret sits encrypted. Opening the page shows a button, nothing more.
After the last allowed open the ciphertext is wiped from the database. Reloading shows a dead end.
Never opened within its 1 hour to 30 days, whatever the sender chose. Wiped all the same.
The sender pulled it back from History. The link stops working immediately and the ciphertext is wiped.
There is no fourth outcome. Every path ends with the encrypted value destroyed.
Chat apps and mail scanners prefetch links. Here, fetching a link never consumes the secret. The reveal is a separate, deliberate click. A one-time secret burned by a preview robot is a secret the recipient never sees, so the design rules it out.
History shows each link's secret names, timestamps and status (active, used up, expired, withdrawn), so you can see what happened and withdraw what should not be out there. The values are gone the moment a link dies.
| Limit | Value |
|---|---|
| Secrets per link | 10 (5 when dropped off by an agent) |
| Total size per link | 64 KB |
| Name length | 200 characters |
| Expiry | 1 hour, 24 hours, 7 days or 30 days |
| Opens per link | 1, 2, 3, 5 or unlimited until expiry |
| Agent drop-off | 24-hour expiry, unlimited opens until expiry, 10 links per hour per address |