Deploy an artifact

Deploying is a single POST. There is no build step, no bundler and no framework convention: the bytes you send are the bytes that get served.

curl -sS -X POST https://api.superart.page/deploy \
  -H "Authorization: Bearer $SUPER_ARTIFACTS_KEY" \
  -H "Content-Type: application/json" \
  -d @deploy.json

The body

{
  "slug": "workout-tracker",
  "metadata": {
    "prompt": "a tracker for my lifting sessions",
    "kind": "tracker",
    "collection": "fitness"
  },
  "files": [
    {
      "path": "index.html",
      "contentType": "text/html; charset=utf-8",
      "sha256": "e3b0c442…",
      "content": "PGh0bWw+…"
    }
  ]
}

content is base64. sha256 is the hex digest of the decoded bytes; the server recomputes it and refuses a mismatch, so a truncated upload fails at deploy time instead of quietly serving a corrupt file. contentType is optional and inferred from the extension.

metadata.prompt is required — one sentence saying why the thing was built. kind is one of page, slideshow, survey, tracker, video or tool, and nothing else. A closed set rather than free text because once agents pick the value, an open vocabulary is one where slideshow, slides and deck are three groups holding the same thing.

What comes back

The response carries the artifact's id, the version it just wrote, and the url. Copy that url field exactly — never retype it, never reconstruct it, never wrap it in emphasis. A renderer that glues a zero-width space onto the end produces a 404 on an artifact that is perfectly fine, and that has already happened to somebody.

Two things about bundles

• Use relative asset paths. <script src="app.js">, not /app.js. Root-absolute paths resolve against the artifact host's apex rather than your artifact. The worker recovers most of them from the Referer header, but that is a net, not a supported path.
• The trailing slash is load-bearing. GET /{id} answers 301 to /{id}/, because without it every relative link inside the bundle resolves one level too high.