One-time view links: pages that burn after reading.

How the first view burns the page

Burn-after-read is a publish flag: set it from the API, from any MCP agent, or flip it onto an already-published page. From then on the page is armed.

When a request for the page arrives and clears its gates, the worker runs one conditional update against the database: set the burned timestamp, where burn is enabled and the timestamp is still empty. That single statement is both the check and the claim. If it changes exactly one row, this request won the view and the page is served. If it changes zero rows, someone already won, and the response is a 410 Gone: "this site has been viewed and removed."

Because the check and the claim are the same atomic statement, there is no read-then-delete window in which two viewers could both see the content. Two clicks in the same instant resolve to one winner; the losing request never touches the stored files. The actual teardown, deleting the files and then the site record itself, runs immediately after the claim, off the response path. The door closes at the claim, not at the deletion.

Will a preview or a scanner burn it?

This is the question that decides whether a burn tool is usable, so here is exactly what the code does.

Stacktree does not guess which requests are human. There is no user-agent list deciding that Slackbot does not count. The first request that reaches the page document and clears its gates takes the view, whoever sent it. What protects the view is construction, not heuristics:

• The preview image can never burn the page. When a chat app renders a link card, the thumbnail comes from a separate image endpoint that never opens the page. For a burn page it serves a generic locked graphic, a lock mark with "This page is private" and a SINGLE-VIEW ONLY chip, composed only from the page's metadata record: no title, no description, no content. Stacktree also skips its usual publish-time screenshot for burn pages, so no rendering of the content ever exists outside the page itself.
• The page fetch is where the risk lives. Chat apps also request the URL itself to read its meta tags, and corporate mail filters such as Microsoft Safe Links open links in email to scan them before the recipient can. On a burn page with no other gate, that fetch is indistinguishable from a reader: it consumes the view, and your recipient gets the 410. Every burn-after-read tool has this failure mode; user-agent heuristics only hide it until the next scanner shows up.

Which is why the feature is designed to be combined with a password.

The safe pattern: burn plus password

Gates run before the burn claim. A password-protected burn page challenges every request first (HTTP basic auth in the browser, no account for the viewer), and the burn statement only executes after the gate passes. That ordering does the work:

• A preview scraper or link scanner hits the URL, gets a 401 challenge, and goes away. Nothing burns.
• Anyone who intercepts the bare link is in the same position: the URL alone opens nothing and spends nothing.
• Your recipient enters the passcode, the gate passes, the claim fires, and they see the page: the first and only view.

Send the link and the passcode over different channels: the link in the email, the passcode in a text or a call. An intercepted link cannot spend the view, and an intercepted passcode is useless without the link. Password gates are free on up to 3 sites, unlimited on Pro.

After the burn: what everyone sees

The second visitor gets a 410 with one line: "this site has been viewed and removed." Once cleanup completes, moments later, the record is gone entirely and the URL returns a plain 404, the same response as a token that never existed. Unlisted URLs live in an unguessable token namespace that is disallowed for crawlers and served with noindex headers, so the dead link confirms nothing to anyone who finds it in a scrollback later.

For you, the sender: the page disappears from your dashboard, and that disappearance is the read receipt. The burn deletes the site record itself along with the files, the view log, and any viewer reactions, notes, and engagement data, so there is no notification email and no "opened at 3:41pm" entry kept afterwards. If you need a timestamped delivery log, this deliberately is not the surface for it.

Two practical notes:

• The first open is the view, even if it is yours. There is no owner exception on the claim. Do not open the link to check it; publish a copy without burn if you want to see what the recipient will see.
• Combine burn with an expiry. If the recipient never opens the page, an expiry ends the link on schedule anyway; expiry is checked before anything else on every request. Agents publishing over MCP get a 7-day expiry by default.

What burn is, and what it is not

Burn is deletion, not DRM. The one viewer who opens the page has it: they can read it, save the HTML, print it, screenshot it, repeat what they learned. If your threat model is the recipient, no self-destructing anything will help you. What burn guarantees is narrower and worth having anyway: the link stops working, so the page cannot keep leaking after the moment it was read, out of a forwarded email, a shared channel, or a browser history.

Two more honest limits:

• One self-contained file. The claim fires on the page document, and every request after it is refused, including requests for the page's own assets, so a burn page should be a single HTML file with its styles and data inlined. In practice that is the shape agent-written pages already have: in our own publish data, 99% of agent-published pages are a single self-contained file. (Stacktree's end-to-end encryption is a separate mode whose decryption step fetches an encrypted payload after the page loads, which does not fit burn's one-request claim; treat the two as alternatives, not a combo.)
• The server can read it until it burns. A burn page is stored like any other page. Privnote-class tools encrypt in the browser so the operator cannot read the note at all; a Stacktree burn page does not have that property. Related, and deliberate: the PII pre-flight scan blocks an agent publish that contains detected API keys, emails, or card numbers by default. When the sensitive content is the point, the agent overrides that with pii_check: "warn", on purpose.

Compared with Privnote and one-time-secret tools

Privnote, One-Time Secret, Yopass, PrivateBin: good tools, and if what you are handing over is one password string or a short note, use one of them. They are simpler (paste, get a link, done), and several encrypt client-side by default, a stronger confidentiality property than a burn page has here.

What they share is that the payload is text. The note arrives as a paragraph inside the tool's own wrapper page.

A one-time view link is a full rendered page. The thing that burns is the deliverable itself: a styled credentials pack, an offer letter that looks like an offer letter, an incident report with its charts and timeline intact, whatever an agent produced as HTML in the first place. And it composes with the rest of the hosting rather than living in a separate paste-a-secret workflow: a password gate in front, expiry underneath, the same unguessable URL namespace, and publishing through the same MCP tools the agent already uses.

Publishing one from an agent

Burn is a flag on publish, so an agent can mint a one-time link in a single tool call. Over MCP (Claude Code, Claude.ai via the connector, Codex, Cursor, any MCP client), publish_html accepts burn_after_read, password, and expires_in_hours together:

publish_html({
  content: "<!doctype html>...",
  burn_after_read: true,
  password: "delivered-separately",
  pii_check: "warn"  // deliberate: the sensitive content is the point
})

The MCP defaults are tuned for exactly this kind of material: an unguessable token URL, a 7-day expiry, and a PII scan that fails the publish if it detects secrets, unless the agent overrides it explicitly. The same flag exists on the raw API (burn_after_read=true on the upload) and can be switched on for an already-published page with a PATCH.

For the wider handoff flow, per-recipient links, revocation, and gates without the self-destruct, see share an HTML file with a client.