Artifact Site Publish Request and Canonical Share Updates
How the Publish site action works for workspace-backed sites, what publish success and failure states mean, and how repeated publishes affect the canonical share URL.
Artifact Site Publish Request and Canonical Share Updates
Where you see this in the app
This page explains the Publish site action used for workspace-backed artifact sites.
Users normally encounter it on a post that already has a workspace and a publishable site structure. The action is meant for authors who want the current workspace output to become the public artifact-site version.
What Publish site does
Publish site takes the current publishable site output from the workspace and turns it into the public shareable artifact-site version for that post.
This is different from replacing a single attached file. Publishing a site is for a multi-file site experience, not for swapping one uploaded artifact file.
Users should expect:
- the action is author-focused,
- the workspace must be in an editable state to publish,
- the result is a site-style share target, not just a raw file replacement.
Success result and share fields
When publishing succeeds, the app can return share fields that describe the resulting site target.
Typical fields:
| Field | Meaning |
|---|---|
shareId | Internal identifier for the current published share target |
sharePath | The canonical share route for the published site |
openPath | The path the UI can open immediately after success |
End users do not need the internal mechanics. They only need to understand that a successful publish gives the post a stable public site destination.
Canonical URL on republish
Republishing is normally an update to the same public destination, not the creation of a brand-new public address each time.
That means:
- the published site URL is expected to stay stable,
- newer publishes replace the visible site content behind that stable route,
- sharing the canonical artifact-site link remains valid after later updates.
This is why users should think of publish as updating the live site version, not minting a new permalink for every revision.
Common errors and misleading expectations
Common user misunderstandings:
| Situation | Correct expectation |
|---|---|
| Viewer tries to publish | Publishing is an author/edit-mode action |
| Workspace preview works but publish fails | Preview readiness and publish readiness are related but not identical |
| User expects a new URL every publish | Republish usually updates the same canonical share target |
| User confuses publish with file replacement | Publishing a site is different from replacing a single attachment |
If publishing fails, the most likely issue is edit access, missing publishable output, or workspace readiness, not a problem with the share URL itself.
Related docs
Related docs
See it in action
Previous
Artifact Attachment Replacement and Commit Flow
How single-file artifact attachment replacement works for authors, what upload URL and commit mean in practical terms, and how this differs from publishing a multi-file artifact site.
Next
API Tokens, Webhooks, and Account Controls
The browser-level guide to PATs, webhooks, notifications, usage, AI credits, and custom domains.