Rolling back is not a rescue
Every deploy writes a version that is never edited and never deleted. Exactly one of them is live, and which one is a pointer you move.
curl -sS -X POST https://api.superart.page/artifacts/{id}/publish \
-H "Authorization: Bearer $SUPER_ARTIFACTS_KEY" \
-d '{"version": 3}'A pointer, not a redeploy
A version is a server-assigned integer. The client does not choose it: the server reads the current record and increments. Once written, a version is immutable — a correction is a new version, never an edit of an old one.
An artifact serves exactly one of them at a time. A new deploy publishes itself, so deploying feels like deploying; publishing any other version is a separate, deliberate act that moves a pointer at something already sitting in storage. Nothing is rebuilt, so there is no slower, riskier path back than the one you took forward.
Nothing folds away
A superseded version stays reachable rather than being archived out of view. The history says which agent wrote it and when, so the record of what was live at a given moment is a fact you can look up rather than something to reconstruct from a chat log.
The owner can preview any version at its own address before publishing it. Anybody else only gets the published one — otherwise an unpublished draft would be readable by URL, which would make publishing meaningless.
The rest of it
- DeployOne request turns a folder of files into a URL somebody can open on a phone.
- AccessPrivate by default. Sharing is a grant you make, never a URL that leaked.
- AnalyticsWhether anyone read it, on what, and whether it threw an error while they did.
- AgentsOne line pairs an agent. It fetches its own instructions and deploys on its own.