Self-destructing links

A view limit caps how many times a document can be opened. Once the limit is reached the link stops working, and shortly afterwards the stored file is destroyed — after that nobody can open it, including you, even with the link in hand.

Setting a view limit

View limits are available on the Basic plan and above; a Free account setting one is refused with HTTP 403. After you upload a file, open the link settings and set a View limit to the number of times the document can be opened. Setting the limit to 0 clears it and removes the restriction; a negative value is rejected with HTTP 400.

A view is consumed once per viewing session, and only at the point where the document's bytes are about to be served: after the password and email gates have passed, after the download-permission check has allowed the request, and after the stored file has opened and decrypted. A reader who abandons the password prompt or the email gate, or whose request fails for any other reason, does not spend a view. Once a session has consumed its view, that session can refetch the bytes freely, so page reloads and range requests within it cost nothing further. Your own views as the owner never count. If you set a limit of 3, three viewing sessions consume the document and the fourth is refused.

What happens when the limit is reached

As soon as the last view is consumed, further viewers are refused with an HTTP 410 error — "This link has reached its view limit". Nothing has been deleted yet at this point.

Destruction happens shortly afterwards. A background sweep runs every 60 seconds and destroys the encrypted file on disk once the limit has been reached for at least 30 minutes. That grace window exists so readers who are mid-session when the limit is hit can finish reading. Only the encrypted bytes are removed; the document's database record, its settings, and its readership history are all left in place.

Once the sweep has destroyed the file, the 410 applies to everyone, including you as the document owner — you can no longer preview or download it. During the grace window before the sweep runs, the document is still readable by you as the owner, because owners never consume views and the bytes still exist.

This is by design: the view limit is a hard boundary, not a soft warning. If you need to review the document after sharing it, do so before you run out of views.

Destruction also flips every settings lane closed: once a document is burned, the settings endpoint, the download-permission toggle, and the viewer-mode endpoint all answer 410. Content replacement is the deliberate exception (see below).

Readership data survives the burn

Even though the document bytes are gone, your readership data remains. The burn destroys only the encrypted file; the document's row and every record attached to it survive — view sessions, viewer countries, timestamps, per-page statistics, and any captured emails or lead-form responses. Preserving that evidence is the point: the feature exists so you can learn who opened a document, not so the record of it disappears with the file.

Extending or removing the limit

You can change the view limit at any time while the document is still live. Increasing it allows more sessions; clearing it (setting it to 0) removes the restriction entirely, leaving the link live until its expiry. Consumed views are not reset by a settings change, so raising a limit of 3 to 5 grants two further sessions rather than five.

Once a document has burned, the settings endpoint refuses writes with 410, so the limit can no longer be changed there.

The un-burn path: replacing content

If a document burns but you want the link to work again, replace the document's content. Uploading new content to an already-burned link brings it back to life: the burn state is cleared and the consumed-view counter is reset, while the URL, short ID, vanity slug, settings, and readership history all survive. The view limit itself is kept, so the new document is subject to the same cap from zero.

This is the only way to resurrect a burned link, and it is deliberate — content replacement refuses documents that have expired with 410, but accepts burned ones. Note that content replacement requires a Pro plan, so a Basic account can set a view limit but cannot un-burn the resulting link.

Related features

• Expiry and retention — Set a time-based expiration instead of or in addition to a view limit
• Dynamic links — Replace document content and use content replacement to un-burn a link
• Webhooks — Receive a file.burned event, emitted by the sweep at the moment it destroys the file, not when the limit is reached
• Readership analytics — Understand what data survives after a document burns