How LinkPilot Secret Links work.

1. Overview

LinkPilot runs two distinct link pipelines on the same platform: Smart Links for branded short URLs with click analytics, and Secret Links for one-time, expiring, passphrase-protected delivery of sensitive content. They are kept apart at the data, code-path, and product level so that secret payloads can never bleed into analytics dashboards, dataset exports, or AI features.

This page describes the Secret Links pipeline specifically: how a secret is created, how it is revealed, what happens after it is viewed, and what metadata is logged along the way.

2. How Secret Links work

1. The sender creates a secret with optional passphrase, expiry window, and burn-after-views limit.
2. The payload is written to a dedicated secret_links table, isolated from the click-analytics tables.
3. LinkPilot returns a short URL (e.g. shrd.link/s/<slug>) to share with the recipient.
4. When the recipient opens the link, the app calls the secret-reveal edge function. A GET returns metadata only (status, whether a passphrase is required). A POST with the passphrase is what actually reveals the payload.
5. A successful reveal is recorded atomically and may immediately mark the secret as burned, depending on the burn-after-views setting.

3. Encryption model

We want to be precise here, because the words "encrypted" and "zero-knowledge" are often used loosely.

• In transit: all traffic is TLS-encrypted end to end between the recipient, our edge, and our managed database.
• At rest: secret payloads are stored in a column logically separated from analytics data, on a managed Postgres instance with disk-level encryption.
• Passphrases: hashed with SHA-256 on the client before transport, then compared by hash on the server. The plaintext passphrase is never written to our database or logs.
• What we do not currently claim: end-to-end encryption with a recipient-only key. An operator with database access could read an active secret's payload, the same as with any managed-database product. The strongest defenses are short expiry windows and burn-after-read.

If end-to-end client-side encryption matters to your workflow, tell us — it is on the roadmap and we want to ship the right design rather than a misleading label.

4. What happens after a secret is viewed

• The view is recorded atomically through a database function — concurrent reveal attempts cannot leak the secret twice.
• If the view-count limit is reached, the secret's status flips to burned and the stored payload is overwritten with [REDACTED].
• Subsequent reveal attempts return a clear "already viewed and destroyed" response with HTTP 410.
• The audit timeline records every view, burn, and revoke event with a hashed IP — useful for incident response and credential rotation.

5. Expiration and revocation

• Every secret can carry a time-based expiry (5 minutes to 30 days) and an optional view-count cap.
• Expired secrets are flipped to expired on the next access and the payload is redacted in the same write.
• The owner can revoke a secret manually at any time from the dashboard. Revoked secrets immediately refuse to reveal and return HTTP 410.
• Once a secret is burned, expired, or revoked, the payload cannot be recovered through the product — there is no "unrevoke" or "restore" action by design.

6. Passphrase protection

• Passphrases are optional but recommended for any secret you do not want a stray viewer to consume.
• The passphrase is SHA-256 hashed in the browser, sent over TLS, and compared by hash on the server. The raw value never reaches our database.
• We rate-limit passphrase attempts to 5 per IP per minute per secret, enforced across an in-memory limiter and a database-backed sliding window.
• Every failed attempt is written to the audit log with a hashed IP so workspace owners can see suspicious activity.
• We recommend sending the passphrase through a different channel from the link itself — for example, the link by email and the passphrase by Slack DM or SMS.

7. Link scanner and preview-bot protection

Email security scanners and chat-app link unfurlers (Slack, LinkedIn, iMessage, Outlook) routinely fetch URLs as soon as they appear. For a burn-after-read link, a naive design would mean the very first preview destroys the secret before the recipient sees it.

LinkPilot prevents that in three ways:

• Separate metadata and reveal endpoints. A GET on the reveal endpoint only returns the status and whether a passphrase is required. A view is only recorded on an explicit POST reveal, which is the action a human takes after clicking the reveal button.
• Passphrase gate. When a passphrase is set, no payload is returned to anyone — bot or human — without the correct hash.
• Cache-Control: no-store on every reveal response, so intermediaries do not cache secret contents.

8. What metadata is logged

For each reveal attempt we record only what is needed to give workspace owners a credible audit trail:

• Timestamp of the attempt.
• Hashed IP: SHA-256 of the client IP combined with a daily-rotating salt, truncated to 32 characters. The raw IP is never stored.
• Coarse geolocation (country and city) from the edge, when the upstream provides it.
• User-Agent string reported by the client.
• Event type: created, viewed, failed_passphrase, burned, expired, revoked.

We do not log: the secret contents, the raw passphrase, the raw IP address, cookies on the recipient (there are none), or any third-party tracking pixels.

9. Difference between Secret Links and analytics links

The two pipelines share the same brand, dashboard, and team controls — but the data flows do not cross.

10. FAQ