> ## Documentation Index
> Fetch the complete documentation index at: https://docs.octavehq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What are Assets in Octave?

> Assets are Octave-hosted deliverables — microsites, decks, documents, and file bundles — with privacy controls, email-verified share links, version history, and viewer analytics.

## What is an Asset?

An Asset is a deliverable Octave hosts for you: a personalized microsite for a target account, an HTML one-pager, a rendered deck, or a downloadable file bundle. Instead of attaching files to emails or juggling external hosting, you publish once and share a link — and because Octave serves the asset, you also see exactly who opened it and when.

Assets come in three types:

| Type      | What it is                                                                                                |
| --------- | --------------------------------------------------------------------------------------------------------- |
| `website` | A hosted site served at its own URL, with an entry point (e.g. `index.html`)                              |
| `storage` | A downloadable bundle of files                                                                            |
| `skill`   | The backing folder of a managed [Skill](/concepts/skills) — managed through the Skill API, read-only here |

## Privacy, publishing, and sharing

Two independent controls govern who can see an asset:

* **Privacy** is an ordered ladder: `only_me` (owner only) → `workspace` (owner plus workspace members, the default) → `public` (anyone with the URL).
* **Status** is the lifecycle: `published` (discoverable, the default) or `unpublished` (hidden, still readable by its id). Publishing does **not** make an asset public — only the privacy tier does that.

For anything between fully private and fully public, **share links** grant access to specific outsiders without changing the privacy tier. A share link carries an allowlist of exact emails and/or whole domains; viewers verify their address with a one-time code, so every visit is attributed to a real person. Links can expire on a schedule or live forever, and revoking one cuts off its viewers immediately.

When someone without access lands on an asset, they can submit an **access request**. Requests queue in an inbox where you grant (mints a single-recipient share link) or dismiss them.

## Versions

Every file update mints an immutable version. Rolling back is an instant pointer flip — the asset's URL serves the chosen snapshot immediately, and newer versions stay restorable, so you can roll forward again the same way. Version numbers are never reused.

## Analytics

Assets answer "how is it doing?" and "who opened it?":

* **Stats** — per-day unique visit and download counts.
* **Visitors** — every code-verified viewer with open counts and first/last-seen times.

Both are owner-only: teammates can view a shared asset, but never its analytics.

## Managing Assets via API

Creating an asset (the file upload itself) happens against the artifacts service with a per-user access token — see [Publishing Assets via API](/v2-api-reference/asset/publishing-assets) for the full flow. Everything after creation is plain REST:

* `GET /api/v2/asset/list`, `GET /api/v2/asset/get` — discover and inspect
* `POST /api/v2/asset/update` — identifier, description, privacy, status, vanity slug
* `DELETE /api/v2/asset/delete` — permanent removal
* `GET /api/v2/asset/stats`, `GET /api/v2/asset/visitors` — analytics
* `GET /api/v2/asset/versions/list`, `POST /api/v2/asset/versions/restore`, `DELETE /api/v2/asset/versions/delete` — version history and rollback
* `GET|POST|DELETE /api/v2/asset/shares/*` — create, list, revoke, and edit share links
* `GET|POST /api/v2/asset/access-requests/*` — the access-request inbox
* `POST /api/v2/asset/access-token/*` — mint or rotate the upload token

The same operations are available to AI assistants through the [MCP asset tools](/mcp/available-tools#assets).