Artifacts overview

An artifact is a versioned HTML document stored against a workspace. Artifacts are 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.

Proof-of-concept endpoints

These endpoints exist so Plane Intelligence can host the dashboards it generates. They are not a general integration surface. Before you build on them, know that:

• The scope is 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, these endpoints have not been through a public API review, so treat them as unstable.

These endpoints do not return the dashboards a workspace already has.

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

This permission requirement is stricter than most of Plane. Every member can view dashboards, but only workspace admins and owners can read or write artifacts.

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 makes that version current. The server keeps earlier versions, but v2 has 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

Two of these routes end in a verb segment. Appending a version is PATCH …/{artifact_id}/update/, not PATCH …/{artifact_id}/, and publishing is a POST to …/{artifact_id}/publish/.

The generate-and-host flow

These endpoints are built for this sequence:

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 always points at the current version, so you only need to publish once.

Response shaping

These are APIView endpoints. Like current user and workspace features, they do not accept ?fields= or ?expand=, and 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.