Artifacts overview

An artifact is a versioned HTML document stored against a workspace — the storage and hosting layer behind Plane's AI-generated dashboards. Each artifact has a name, an optional project scope, a data mode, and an append-only chain of HTML versions.

This is a POC surface, not a general integration surface

These endpoints exist so Plane Intelligence can host the dashboards it generates. Two consequences worth knowing before you build on them:

• Scope is deliberately narrow. Create, read, append-a-version, and publish. There is no list endpoint, no delete, no way to read an older version, and no way to unpublish.
• The shape may still change. Unlike the rest of v2, this surface has not been through a public-API review, so treat it as unstable.

If you are looking for the dashboards a workspace already has, this is not that API.

Requirements

Every artifact endpoint enforces both of these:

Requirement	Failure
The Applets feature enabled on your plan	402 payment_required
Workspace admin or owner	403 forbidden

The permission requirement is stricter than most of Plane. Dashboards are viewable by every member; artifacts are admin-and-owner only, for reads as well as writes.

The artifact object

Attributes

• id string (uuid)

  Unique identifier for the artifact.

• name string

  Display name. Maximum 255 characters. Defaults to Untitled dashboard when created without one.

• description string

  Free-form description. Maximum 2000 characters. Returned on the detail read only.

• html string

  The rendered HTML of the current version. Returned on the detail read only.

• current_version integer

  Which version is current. Starts at 1 and increments by one each time you append a version.

• data_mode string

  How the artifact's data is sourced — snapshot (data frozen at generation time) or live (re-read on view). Defaults to snapshot.

• is_published boolean

  Whether the artifact has a public anchor. Returned on create.

• anchor string

  The public anchor once published, otherwise null. Returned on create and publish.

Versions are append-only

Updating an artifact does not overwrite its HTML — it creates version current_version + 1 and moves the pointer. Earlier versions are retained server-side, but v2 exposes no endpoint to read them.

Response200

{
  "id": "b7e42a19-3c5d-4f80-9a26-8d1c0f4e7b53",
  "name": "Q1 velocity by squad",
  "description": "Throughput and cycle time, split by squad.",
  "current_version": 3,
  "data_mode": "snapshot",
  "html": "<section><h1>Q1 velocity by squad</h1>…</section>"
}

Endpoints

Method	Path	Description
GET	/api/v2/workspaces/{slug}/artifacts/{artifact_id}/	Get an artifact
POST	/api/v2/workspaces/{slug}/artifacts/	Create an artifact
PATCH	/api/v2/workspaces/{slug}/artifacts/{artifact_id}/update/	Append a new version
POST	/api/v2/workspaces/{slug}/artifacts/{artifact_id}/publish/	Publish an artifact

Note the two verb sub-paths. Appending a version is PATCH …/{artifact_id}/update/, not PATCH …/{artifact_id}/, and publishing is a POST to its own segment.

The generate-and-host flow

The sequence these endpoints were built for:

1. Create the artifact with its first HTML version — POST …/artifacts/.
2. Publish it to get a shareable anchor — POST …/artifacts/{id}/publish/.
3. Append a new version whenever the content is regenerated — PATCH …/artifacts/{id}/update/. The anchor keeps pointing at whatever is current, so publishing once is enough.

Response shaping

These are APIView endpoints, so — like current user and workspace features — they do not accept ?fields= or ?expand=. Each returns its own fixed shape.

Errors otherwise follow the shared problem+json contract, with one exception noted on the write pages: the html-missing and data_mode-invalid validation failures return a bare {"detail": "…"} body rather than the standard {type, code, detail} envelope.