Artifact Site Expiry, Revoke, and Share Lifecycle

Where you see this in the app

This page documents the author controls shown after an artifact site already exists.

On the artifact/share surface, authors can encounter actions such as:

• Open site
• Revoke link
• Expire in 24h
• a follow-up action that clears expiry if one is already set

Open, revoke, and expire in 24h

These controls manage the existing share link. They do not create a brand-new site by themselves.

Users should think of this as share lifecycle management, not as publishing.

What viewers see after revoke or expiry

Once a link has been revoked or has passed its expiry time, viewers should expect that the old share link stops working.

From a user perspective:

• revoked means the link has been intentionally turned off,
• expired means the link has timed out,
• both states are different from paywall or sign-in restrictions.

This distinction matters because a revoked or expired link is not fixed by purchasing access alone.

Clearing expiry vs republishing

Clearing expiry keeps the same share alive.

Republishing is different: it updates the published site content behind the canonical share target. In practice, these are two different management tools:

• clear expiry if you only want the current link to remain valid,
• republish if you want newer site content to become the live version.

How to think about share-link lifecycle

A good end-user mental model is:

1. Publish a site to create or update the canonical share target.
2. Manage that target over time with revoke and expiry controls.
3. Republish when the content changes materially.

That keeps authors from confusing link management with content publishing.

Related docs

• Workspace attachments, published site, and share links
• Artifact site publish request and canonical share updates
• Post purchase states and access CTAs