Password-protect, expire, or revoke a link you've already sent

The worst property of an email attachment is that it's permanent. Once it's sent, it exists forever, on a disk you don't control, forwardable to anyone, with no way to take it back.

A link doesn't have that problem. The file stays on a server, and the link is just permission to look at it — permission you can narrow, time-limit, or withdraw entirely, including after you've sent it.

Here's the full set of controls and, more usefully, which one to actually use.

The controls

Every one of these lives on a link's config page in the dashboard, and can be changed at any point in the link's life.

Control	What it does	Reach for it when
Password	Viewer must type a password before the document renders	The recipient list is small and you can share a password out-of-band
Expiry date	Link stops working after a date and time	The document has a natural shelf life — a quote, an offer, an embargo
Max views	Link locks itself after N opens	You're sending to one person and want it to stop being useful once read
Email gate	Viewer must enter their email before opening	You want to know who's reading, including forwards
Allowed domains	Only addresses at listed domains get through	Sharing with one company — `@acme.com` only
Blocked emails	Named addresses are refused	A specific person shouldn't have it any more
Approval requests	Unknown viewers request access; you approve or don't	You don't know the full list up front and want to decide case by case
Deactivate / delete	Link stops working immediately, for everyone	You sent the wrong thing

Which one you actually want

Most people reach for a password out of habit. Usually it's the wrong tool.

Sharing with one company? Use allowed domains, not a password. You set acme.com once, and anyone with an Acme address gets in with no shared secret to leak, forget, or send in the same email as the link (which people do constantly, and which defeats the point entirely).

Don't know who'll need it? Use approval requests. The viewer enters their email, and if they're not already allowed, they can ask. You get a notification, approve with one click, and they're in. You end up with an audit trail of exactly who asked and who you let in.

Just want to know who's reading? Use the email gate on its own. It doesn't block anyone — it asks for an email first, which means forwards show up as named people instead of anonymous opens.

Genuinely sensitive, small audience? Now use a password, and send it through a different channel than the link. Combine it with an expiry date.

Time-limited by nature? Set an expiry. A quote that expires on the 31st should have a link that expires on the 31st — it does the chasing for you, and it's a better prompt for a follow-up call than a reminder in your calendar.

Recovering from a link you've already sent

This is the part people don't realise they can do.

Wrong file attached to the right link. Don't send a new link — replace the file behind the existing one. Same URL, same slug, same settings, and the analytics history survives. Everyone holding the link now sees the correct version. If you have an assistant connected over MCP, "update the link I already sent" is enough.

Sent to the wrong person. Add their address to blocked emails, or switch the link to an allowed-domains list that excludes them. Existing copies of the URL stop working for them specifically.

Sent the wrong thing entirely. Deactivate the link. It stops resolving immediately, for everyone, and you keep the analytics. Deleting also works but throws the history away — deactivate first, delete later if you're sure.

It's been out there too long. Add an expiry date, in the past if you like. Or set max views to the number it's already had.

The thing worth internalising: none of these are decisions you make at send time. You can tighten a link that's already in someone's inbox.

What this doesn't stop

Access control on a link controls access to the link. It cannot control what someone does once they've legitimately opened the document:

A determined viewer can screenshot any page they can see.
If downloads are allowed, the file leaves and is out of scope.
A password shared onward works for whoever it's shared with.

What you get is control over the distribution channel plus a record of who used it — which is the realistic goal. If a document genuinely cannot be seen by the wrong person, the answer is not to send it, and no link setting changes that.

For how the underlying storage, transport and access checks work, see Security.

Setting it at creation time

If you'd rather not visit the dashboard, the same controls are available at creation:

curl -s -X POST https://slim.to/api/v1/links \
  -H "X-API-Key: $SLIMTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "target_url": "https://example.com/quote",
        "title": "Q4 quote",
        "password": "correct-horse",
        "expires_at": "2026-09-30T23:59:59Z",
        "max_views": 5
      }'

Full field list in the REST API quickstart. Password, expiry and slug are also available as arguments to the MCP tools, so an assistant can set them as it creates the link.