Link Expiry Settings: Choosing a Window That Matches the Deal

A shared link is not a document. It is a running service that keeps answering requests until something tells it to stop. This guide covers how to choose that stopping point, what happens to the data afterwards, and why expiry and retention are two different decisions that people routinely collapse into one.

Why a link that outlives its deal is a liability

Every live link is a small standing obligation. It can be forwarded. It can be pasted into a Slack channel that a contractor joins next quarter. It can sit in an email thread that gets subpoenaed, or handed to a procurement team at the buyer's competitor. None of that is exotic — it is just what URLs do when nobody expires them.

Three concrete failure modes show up again and again:

• Stale pricing becomes a negotiating weapon. Last year's discount structure, still reachable, still screenshot-able, is now the buyer's opening position.
• Superseded material gets treated as current. A prospect bookmarks the first proposal, never opens the revised one, and argues from a version you abandoned.
• Your exposure window is unbounded. A link with no end date can only be closed by someone remembering it exists. Memory is not a control.

Expiry converts an open-ended risk into a fixed one. After the window closes, the URL returns a dead page instead of your content — no scramble, no cleanup ticket, no "who still has this." If you want the mechanics of setting one from scratch, the walkthrough in how to create expiring HTML links securely covers the click path; this guide is about choosing the number.

Expiry vs. data retention: two clocks, two jobs

This is the distinction worth getting right, because the two controls answer different questions.

Expiry governs access. It decides when the recipient stops being able to load the page. The link and its analytics still exist on your side; visitors just can't reach the content.

Data retention governs existence. It decides when HTMLvault deletes the underlying record — the HTML itself and the analytics attached to it. Retention is the answer to a compliance question ("how long do we hold this?"), not a sales question.

The practical consequence: a link can be expired and still retained, which is usually what you want — the deal is over, but you'd like to know the buyer's legal team read page four twice. The reverse also happens: an aggressive retention window can purge a link that is technically still live, at which point access ends because there is nothing left to serve.

How to choose an expiry window

On HTMLvault, expiry is configurable per link on Pro and above, anywhere from one hour to never. Free links carry a fixed 30-day expiry, which is a reasonable default for most one-off shares.

The method is simple: start from the decision the link supports, not from the calendar. Ask how long the recipient legitimately needs to reference the content, add a small buffer for the human reality of vacations and forwarded threads, then stop.

1. Identify the decision. Is this a live negotiation, a scheduled review, a campaign preview, or a permanent reference page?
2. Match the window to that cycle. A pricing sheet lives as long as the pricing is valid. A landing page lives as long as the campaign runs.
3. Add one buffer unit, not three. If review takes a week, set two. Don't set a year.
4. Layer controls where the content warrants it. Expiry limits time; a password on the link limits who, and the two together are much stronger than either alone.

Rough starting points, adjusted to your own cycle:

• 1–24 hours: a credential handoff, a one-time internal review, anything you'd rather not exist by tomorrow.
• 7 days: a proposal in active negotiation, a demo follow-up, an executive summary before a call.
• 30 days: the workhorse. Pricing under evaluation, a lead list handed to a partner, training material for an onboarding cohort.
• 90 days: a quarterly dashboard, a campaign landing page with a defined end, a security questionnaire response.
• Never: genuinely permanent reference material with nothing sensitive in it. Use this deliberately, not by omission.

One habit worth building: when a deal closes — won or lost — expire the links attached to it. Won deals move to a contract and a customer portal. Lost deals should not leave your pricing reachable by a buyer who chose someone else. Expiry is one of a small set of HTML security controls that only work if they are set before the link is sent, which is why team defaults beat per-link discipline.

The six data retention windows

Retention is set at the account or link level and determines when the stored record is destroyed. HTMLvault offers six windows, and the shape of the ladder matters more than the exact numbers:

• Auto-delete — the record is purged as soon as the link expires. No stored HTML, no analytics history, nothing to produce later. This is the zero-trace option.
• 30 days — enough to review engagement after a deal cycle, then gone.
• 90 days — the Free tier's window, and a sane quarterly default.
• 6 months — covers a two-quarter sales cycle with attribution intact.
• 1 year — annual reporting, renewal-cycle comparisons.
• 2 years — the maximum on Pro, for teams whose audit policy requires a multi-year trail.

Configurable retention (auto-delete through 2 years) is a Pro and above capability. Free accounts retain data for 90 days, with no option to shorten or extend it.

Choosing between them is a governance call, not a preference. Two questions settle most cases: does anyone need to produce this later, and would you rather not have it if someone asks? If the answer to the second is yes, auto-delete exists precisely for that, and the data retention window guide covers the zero-trace pattern in detail.

Worked example: a 45-day enterprise proposal

A rep sends a pricing proposal to a mid-market buyer whose procurement cycle runs about six weeks. Here is the configuration and the reasoning:

• Expiry: 60 days. The 45-day cycle plus one buffer unit. Long enough that nobody hits a dead page mid-review; short enough that it dies well inside the quarter.
• Password: on. The document contains negotiated discounts. Expiry limits the window, the password limits the audience.
• Retention: 6 months. If the deal closes, RevOps wants the engagement data for cycle analysis. If it stalls, the record is gone before the next fiscal year.
• Scan before publish. The regex scanner checks the HTML for the nine categories it detects — including financial identifiers, addresses, and contact data — at zero token cost, since it never calls a model. Worth running on anything with pricing tables in it.

Day 31: the buyer signs. The rep expires the link immediately rather than waiting out the remaining 29 days, because the negotiation document is now superseded by a contract. Access ends that afternoon.

Day 31 through month six: the link is dead, the analytics live on. The team can see that finance spent eleven minutes on the pricing page and legal never opened it — the sort of detail per-link analytics surfaces and that changes how the next proposal is structured. Month six: the record is purged automatically, and nobody files a ticket to make that happen.

If you're building this into a repeatable motion, expiry and retention are both settable through the REST API and the MCP tools — create_link and update_link both accept the window — so a link created by Claude, ChatGPT, or a Zapier step arrives with the right expiry already applied instead of relying on someone to set it after the fact. patch_link is the one to reach for when a deal closes early and you want to shorten a window that is already live.

Limits and caveats

Four things that trip teams up:

• Expiry does not un-copy anything. If a recipient screenshotted the page or saved the HTML, that copy is theirs now. Expiry limits the window of exposure; it does not reach into someone's downloads folder. Pair it with the rest of the controls in sharing HTML without losing control when the content genuinely matters.
• Retention can outrun expiry, and vice versa. A 30-day retention window on a link set to never expire means the link dies at 30 days anyway — there is nothing left to serve. Check that your two clocks agree.
• Purged means purged. Retention deletion is permanent by design. Export any analytics you need for reporting before the window closes; there is no recovery step afterwards.
• "Never" is a decision, not a default. Any link you set to never expire should have a named owner and a reason. Without one it becomes exactly the fourteen-month-old pricing page this guide opened with. Note that "never" is a Pro-and-above choice; on Free every link stops at 30 days whether you meant it to or not.

One more operational note: expiring a link is not the same as deleting it. Deletion removes the record now; expiry closes access and leaves the analytics for you. Reach for delete when the content should never have been published, and for expiry when it simply finished its job. On Teams and Enterprise, both actions land in the audit trail, so "who expired that link and when" is a lookup rather than a conversation.

What this gives you

For the rep, expiry is the thing that stops a closed deal from following you into next year — no spreadsheet of old URLs, no quiet hope that nobody forwards the pricing. For RevOps, retention is the difference between analytics you use and data you merely store. For the IT and compliance stakeholders who approve the tool, the pair together is the answer to the question they always ask: what happens to this content when nobody is watching it anymore.

Set both windows once as team defaults, override per link when a deal warrants it, and the answer becomes documented policy instead of individual memory. If you're evaluating this alongside other options, the pastebin alternative comparison covers where expiry and retention sit among the rest of the controls worth requiring.