Expiring download links and download limits: control after the send

Three controls do the work. An expiry date, so the link stops on a day you choose. A download cap, so it stops after a number you choose. And a way to shut it off on demand — either pausing the link or moving the file to a fresh URL. A link with none of the three is permanent: it works for everyone who has it, forever, including the people you never sent it to.

A shared link is public by default

"Anyone with the link can view" is the default setting on every file sharing tool, and it means what it says. A URL is a bearer token — possession is permission. It has no idea who you meant to give it to, and every copy works as well as the original: forwarded in email, pasted into a group chat, screenshotted, attached to a support ticket, carried out in someone's export when they leave the company.

Replilo slugs are resistant to guessing. Nobody is going to stumble onto one by trying, and that's the wrong threat to be worrying about anyway. The failure that actually happens is mundane: you sent it to six people and one of them was being helpful.

What each control is for

The expiry date

Set it from the file's own shelf life, not from a feeling about urgency. A number that was true in Q3 is a wrong number in March, and the version you'll regret is the one still circulating eighteen months later because nobody remembered it existed. Set the date when you create the link. You will not come back and do it later.

The download cap

Leave headroom. People download twice, lose the file, switch laptops, hit a flaky connection at the airport. A cap set exactly to headcount locks somebody out on a Friday afternoon and the message you get is not a security alert, it's an annoyed colleague.

The cap's real value isn't the ceiling. It's the signal. A link you sent to six people that burns through twenty-five downloads has been forwarded, and you found out because the counter told you rather than because someone mentioned it.

The kill switch

Expiry dates and caps are guesses you make in advance about a future you can't see. The third control is the one you reach for when the guess was wrong, and it comes in two shapes that are not interchangeable.

Pausing and rotating solve different problems

Pausing sets the link inactive. Nobody gets through, including the people who should. The URL survives, so unpausing brings every existing bookmark back to life. Use it when the problem is the file: a wrong figure in the deck, an unannounced date in a footnote, a review you didn't know was pending. Pausing is a hold, and holds are reversible.

Regenerating the slug moves the file to a fresh URL. The old one stops resolving and stays that way. Use it when the problem is the URL — it's in a public thread, in a newsletter, in a Slack export, in a screenshot somebody posted. The document, the subscriber list and the download history all stay put; only the address changes. The cost is real: you now have to reissue the link to everyone who should still have it.

Picking the wrong one fails in a specific way. Pause a leaked link and you've bought a delay, not a fix — the second you unpause it, the leak is live again, because the URL in the public thread is the URL you just switched back on. Rotate the slug over a typo in the file and you've broken every legitimate bookmark to fix something the next upload fixes anyway.

When the link is already out

1. Work out whether the problem is the file or the URL. Everything else follows from that answer, and it takes ten seconds.
2. If it's the URL, regenerate the slug now and deliberate afterwards. The old address stops working immediately and reissuing the new one is a message, not a migration.
3. If you don't know yet, pause. It costs nothing, it's reversible, and it buys you the afternoon.
4. Look at who already downloaded it. The subscriber list and download log tell you how far it travelled and when. Anything already saved is gone — you're establishing scope, not undoing anything.
5. Reissue with an expiry and a cap this time, since you now know what the link is worth.

Setting the controls

Every link in the dashboard carries the same fields: an expiry date, a download cap, a custom slug, an active toggle, and a button that regenerates the slug. Changing any of them takes effect on the next request; there's no republishing step, because the link never pointed at the file directly — it points at the wall in front of it, which is how the email gate works to begin with.

From an assistant connected to Replilo's MCP server, it's a sentence:

> expire the pricing-deck link in 14 days
  and cap it at 25 downloads

→ https://replilo.com/s/ab3xk9qp updated

If you'd rather not watch a counter, the document.downloaded webhook fires on every download, signed with HMAC-SHA256 and retried with backoff, so the download rate turns up in whatever you already monitor. And if you're setting up a first link rather than fixing an existing one, building an email list without a website covers where the link should go.

The short version

Set the expiry when you create the link, because later never comes. Cap it a little above the number of people you sent it to, and read the counter as a tripwire rather than a lock. When something goes wrong, pause if the file is the problem and rotate the slug if the URL is. And don't ask any of it to keep a secret — it keeps a schedule and a record, which is a different and more honest job.