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.
Artifact Attachment Replacement and Commit Flow
Where you see this in the app
This page explains the author-side replacement flow for a single-file artifact attachment on a post.
This is not the same thing as the published multi-file Artifact site share surface.
Single-file artifact vs artifact site
GetPaidX supports two different artifact ideas:
| Surface | What it means |
|---|---|
| Single-file artifact attachment | One uploaded file attached directly to the post, such as an image, PDF, audio file, video, or ZIP |
Artifact site | A published multi-file site that opens through the post's shareable artifact-site flow |
If you are replacing one attached file, you are in the single-file artifact flow, not the site-publishing flow.
Upload URL then commit flow
The current author-side replacement flow is a two-step commit process:
- request an artifact upload URL,
- upload the file to that temporary location,
- call the commit step so GetPaidX makes the new file the post's actual artifact.
From an end-user perspective, this matters because uploading alone is not the same as replacing the live artifact. The commit step is what makes the replacement real.
Author-only and file rules
The current replacement flow follows these rules:
| Rule | Meaning |
|---|---|
| Author-only | Only the post author can manage artifacts |
| Allowed file types only | The file must be one of the supported attachment types |
| Size limits apply by file type | Large files can be rejected if they exceed that type's limit |
| Temporary upload first | The uploaded file must exist at the temporary upload location before commit |
If the temporary upload is missing, the commit step fails instead of guessing.
What changes after commit
After a successful commit:
| Result | What it means |
|---|---|
| Post artifact metadata is updated | The post now points to the new file |
| Old temporary upload is cleaned up | The temp upload location is no longer the live source |
| Artifact update notification is recorded | The app treats the attachment as updated |
So the commit is the boundary between a temporary upload and the actual post attachment readers will access later.
Common mistakes / confusing states
| Situation | What it usually means |
|---|---|
| You uploaded a file but nothing changed on the post | The commit step was never completed |
| The replacement is rejected immediately | The file type, size, or author permission check failed |
| You expected this to update the published artifact site | Single-file artifact replacement and multi-file site publishing are different flows |
Related docs
Related docs
See it in action
Previous
Artifact Site Cookie Bridge and Pub-Host Session Persistence
How the pub host turns a short-lived `gpx_token` redirect parameter into a `gpx_pub_token` cookie, and what that temporary cookie means for signed viewers who keep browsing the published site.
Next
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.