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 is for sales and account teams choosing that stopping point: how long a proposal or pricing page should stay open, when to extend it, and what the account's retention setting removes after it closes. How to set an expiry, step by step, is covered in auto-expiry for time-limited links; this guide is about choosing the number.

Why a link that outlives its deal is a liability

Every live link is a small standing obligation. It can be forwarded, pasted into a Slack channel that a contractor joins next quarter, or passed along by a buyer to whoever they negotiate with next. None of that is exotic. It is what URLs do when nobody expires them.

Three failure modes show up again and again:

• Stale pricing becomes a negotiating weapon. Last year's discount structure, still reachable and still easy to screenshot, becomes 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.
• The exposure window has no end. A link with no end date can only be closed by someone remembering it exists. Memory is not a control.

Expiry turns an open-ended risk into a fixed one. When the window closes, the link stops serving the page, and nobody has to file a cleanup ticket or ask who still has it. It also limits how long anything wrong in the page keeps circulating: a discount quoted too low, or a contact who shouldn't have been named, disappears when the link does. Expiry reduces the half-life of mistakes.

That is also the clearest difference from tools where a page stays up until someone remembers to take it down. The pastebin alternative comparison covers where expiry sits among the other controls to require.

Two clocks: expiry (per link) and retention (account-wide, counted from expiry)

Expiry and retention answer different questions, and they run one after the other, not side by side.

Expiry is set on each link and governs access: the moment recipients can no longer load the page. Until then, the link serves the page and records views. After it, the link record and its analytics are still yours; a visitor just finds the link expired.

Retention is one setting for the whole account. It governs how long an expired link's content and per-visitor view data are kept before they are deleted. In an organization, the owner's setting applies to every member's links. The clock starts at each link's own expiry, not at publishing: a link that expires on 30 June under a 90-day retention window is deleted in late September.

Two consequences follow from that order. A link set to never expire never reaches the retention clock, so retention will never clean it up; only expiring or deleting it will. And because retention is account-wide, one sensitive proposal cannot get a shorter shelf life than the rest. For a single link, the levers are its expiry and deleting it.

What each plan lets you choose:

• Free: every link expires 30 days after publishing, and retention runs up to 90 days.
• Pro, Teams and Enterprise: expiry is chosen per link, from 1 hour to never, and account retention from 7 days to 2 years.

Pick the window from the decision the link supports

On the web, Pro and above choose expiry from fixed steps: 1 hour, 24 hours, 3 days, 7 days, 30 days, 1 year or never. You are choosing a step, not a date, so start from the decision the link supports rather than from the calendar.

Three questions settle most links:

• Purpose. What decision does the link support, and when will it be made? A pricing sheet lives as long as the pricing is valid; a review link lives as long as the review.
• Audience. Who reads it, and how? A single champion reads it the same day. A buying committee passes it around for weeks, and someone on it is always on holiday.
• Sensitivity. What does it cost if the page is still live after the decision? Negotiated discounts and named contacts argue for the shorter step. A product overview with nothing confidential in it can run longer.

Then take the shortest step that covers the decision plus a buffer for vacations and forwarded threads. If the decision lands in two weeks, that is the 30-day step, not 1 year. If nobody can explain why a link needs to be live, it doesn't need to be.

Starting points, adjusted to your own cycle:

• 1 hour or 24 hours: a page shown in one meeting, a one-off internal review, anything you'd rather not exist by tomorrow.
• 3 days: an executive summary ahead of a call, a demo follow-up the buyer will read this week.
• 7 days: a proposal in active negotiation with a close date in sight, a page sent for sign-off.
• 30 days: the workhorse. Pricing under evaluation, a lead list handed to a partner, a proposal going to a buying committee.
• 1 year: a reference page tied to an annual agreement. The web offers this step; the MCP create_link tool does not.
• Never: permanent reference material with nothing sensitive in it. Choose it deliberately, never by omission.

Expiry limits how long; a password on the link limits who. For a page with negotiated terms on it, set both.

Expire on the event, extend on purpose

A calendar window is a backstop. The better trigger is the business event. When a deal closes, won or lost, expire the links attached to it the same day. A won deal moves to a contract, which makes the proposal a superseded document. A lost deal should not leave your pricing with a buyer who chose someone else. An expiry can be changed after the link is sent, so ending one early is a settings change, not a new link.

Extending is the same change in the other direction, and so is the risk: extensions granted by reflex turn a 30-day link into a never-expiring one, a month at a time. Extend when the deal is alive, and look at who has been reading before you do. A slipped deal where the buyer's side opened the pricing twice last week earns an extension. A deal where the geo data puts nine of the eleven views in your own office's city tells a different story: that is your team checking whether the buyer has read it yet. That deal has stalled, and extending it keeps your pricing live for an audience of yourselves.

When an extension is warranted, extend once, to cover the new decision date, and note why on the deal in your CRM. The reason (a procurement review, a new budget cycle) is what tells the next person whether a second extension is justified. The signals that separate a live deal from a polite silence are covered in HTML link analytics for sales.

If the page itself changed while the deal slipped, such as a revised payment schedule or a new start date, update it rather than sending a second link. Editing published HTML without changing the URL keeps the buyer on one version and the analytics in one place.

Choosing the account retention window, and what the purge removes

Retention is set once for the whole account (by the owner, in an organization) and applies to every link after that link expires. Paid plans choose anywhere from 7 days to 2 years; Free goes up to 90 days. There is no per-link retention and no option to delete at the moment of expiry. Retention also cannot be set through MCP or the REST API, so no assistant or automation can change it.

When a link's retention window runs out, its content and its per-visitor view data are deleted. That means the page itself and the detail behind its analytics: who opened it, when, from where, and how far they scrolled. Anything you want to keep from that has to be somewhere else by then.

Choose the window from the longest legitimate reason anyone has to look back at an expired link:

• If engagement goes into the CRM while the deal is live and nobody opens expired pages afterwards, the short end of the range is enough.
• If RevOps compares engagement across sales cycles, or a renewal team wants to see what the buyer read last year, keep it long enough to cover that look-back.
• If a records policy requires you to produce what was sent, the policy sets the number, up to the 2-year maximum.

Every month beyond your real look-back is stored data you will have to account for without ever using. If your account mostly shares sensitive pages and the shortest trail is the goal, the data retention window guide covers how the setting works.

Export first. The purge runs on schedule whether or not anyone exported, so the export should happen when the link expires, not when someone remembers. A link.expired event from webhooks can start a Zapier step or your own script that records the outcome in the CRM, and an AI assistant can pull a link's numbers with get_analytics while the deal is still fresh.

Set it at creation, including from AI tools and automations

There is no organization-wide default expiry and no cap an admin can impose. A link's expiry is whatever was chosen when it was created, or changed to afterwards, so the rule has to live in the places links get made.

On the web, choose the step as you publish. From Claude or another assistant connected through the MCP tools, create_link takes an expiry with the same steps as the web, minus 1 year. Put the rule in the assistant's project instructions ("proposals: 30 days; meeting pages: 24 hours; never use never without saying why") rather than trusting each prompt to mention it. Prompts drift; project instructions stay put.

For automations, make expiry a required field. A Zapier or Clay step, or a script calling the REST API, should set it in the call that creates the link, chosen by the same purpose, audience and sensitivity rule as a hand-made link. An automation that leaves it out is still making the decision, by omission, at whatever volume the workflow runs.

Two settings stay out of automation's reach. Retention is account-wide and set in the account, never per call. Passwords are Pro and above and set per link on the web, from the upload form or the links dashboard; MCP and the API cannot set one, so a link that needs a password gets it from a person after the automation creates it.

A quarterly checklist

• Sweep for links set to never expire, from the links dashboard or with list_links from an assistant, and decide for each one whether that was deliberate.
• Check the expiry your AI tools and automations actually set against what you meant them to set.
• Name an owner for every long-lived link. A link nobody will claim gets expired.
• Export engagement for links whose retention window is about to run out.
• Delete drafts started with create_draft_link that were never finalized.

Worked example: a proposal on a 30-day expiry, extended once when the deal slips

A rep publishes a pricing proposal for a mid-market buyer whose finance lead expects to decide in about three weeks. The page carries negotiated discounts. The account's retention window is one year, because RevOps compares engagement across annual cycles.

• Expiry: 30 days. Three weeks plus a buffer lands on the 30-day step. Seven days would end mid-review; 1 year would outlive the pricing.
• Password: on, set on the web. The discounts justify limiting who can read it, not just for how long.
• Publishing check: automatic. The page is checked against the account's secret and personal-data policy, a regex scan that costs zero tokens, before the link exists.

Day 26: the buyer's procurement review moves two weeks out. Before touching the expiry, the rep opens the analytics. Most views come from the buyer's city, and two visitors have come back to the pricing section more than once. The deal is alive, so the rep extends the link once to cover the new date and notes "procurement review moved" on the opportunity.

Day 40: the buyer signs. The rep cuts the expiry short that afternoon instead of letting the extension run, because the contract now supersedes the proposal. The link.expired webhook tells the CRM the proposal is closed, and the engagement summary goes onto the opportunity.

Over those forty days, the analytics showed the buyer's team spending most of their reading time on pricing and payment terms and barely scrolling into the case studies at the end, the sort of detail per-link analytics surfaces and that changes how the next proposal is structured. A year after expiry, retention deletes the page and its per-visitor data. The summary in the CRM stays.

What expiry does not solve

• Expiry does not un-copy anything. If a recipient took a screenshot, saved the page or retyped the numbers into a spreadsheet, that copy is theirs. Expiry limits the window; it does not reach into anyone's downloads folder. Decide what belongs in the page before it goes out; sharing generated reports securely at work covers the rest of that thinking.
• Expiry does not limit who. A forwarded link works for whoever has it until it expires. A password does that job: it is checked on the server, and changing it ends every earlier unlock at once, which is faster than shortening the expiry when a link has travelled further than planned.
• Expiry changes leave no log. On Teams and Enterprise, the audit trail is the PII audit log, which records one scan event per publish or edit. It does not record who extended an expiry, when a link was deleted or when retention was changed, which is why the reason for an extension belongs on the deal record.
• "Never" is a decision, not a default. A link set to never expire needs a named owner and a reason. Retention will not clean it up, and without an owner it becomes the fourteen-month-old pricing page this guide opened with.

Expiring a link is also not the same as deleting it. Deleting removes the page and its analytics now. Expiring closes access and keeps the analytics until the retention window runs out. Delete when the content should never have been published; expire when it has finished its job.

Set the expiry from the decision date when you publish, extend it once when the buyer's side is still reading, and end it the day the deal closes. A lost deal then leaves you an engagement summary in the CRM and leaves the buyer who chose someone else nothing to open.