Docgent
Install the agent skill
Home For agents Self-host Docs ↗
Integration guide

Three ways in.

All hit the same API, all write to the same git history.

Path A

Agent skill

One command. Any Docgent URL in a thread becomes readable, editable, and reviewable.

Path B

REST API

Direct HTTP from any language, agent harness, or automation.

Path C

CLI

Create, validate and render locally before committing to the store.

Path A — Agent skill

Install docgent-doc-access from the docgent-skills repo. The install flow asks for a per-brand token, verifies it with one cheap call, saves it, and patches AGENTS.md so any Docgent URL routes to the skill instead of an unauthenticated fetch.

openclaw skills install git:Vanaheim-Labs/docgent-skills

Token verification

What "verified" means — the skill runs this check after install:

GET /api/status/<brand>/__token-check__ 404 → token valid, brand reachable 401 → wrong token or wrong brand
The skill fails closed. A brand with no configured token is unreachable — it never borrows another brand's token or routes around auth. If auth fails, the skill surfaces the error rather than silently falling back.

Path B — REST API

Every operation the Studio UI performs is available over HTTP. Authenticate with a per-brand bearer token on every request.

WhatCall
List a brand's documentsGET /api/docs/<brand>?status=&doctype=
Read (any version)GET /api/doc/<brand>/<slug>?ref=<sha>
CreatePUT /api/doc/<brand>/<slug> — no baseSha
UpdatePUT /api/doc/<brand>/<slug> — with baseSha
Propose a rewritePOST /api/rewrite/<brand>/<slug>
Accept a proposalPOST /api/rewrite/<brand>/<slug>/accept
Semantic diffGET /api/diff/<brand>/<slug>?base=&head=
Render committed PDFGET /api/render/<brand>/<slug>?ref=
Preview unsavedPOST /api/preview/<brand>/<slug>
Status / transitionGET · POST /api/status/<brand>/<slug>
Restore old versionPOST /api/restore/<brand>/<slug>
Brand config / assetsGET · PUT /api/brand/<brand>/config
PUT /api/brand/<brand>/assets/<file>

The expected edit loop

For agent rewrites, use propose → accept rather than a raw PUT. This keeps the rewrite in memory until a human accepts it, so the history records one decision rather than every model pass.

# 1. Read — always keep the sha GET /api/doc/<brand>/<slug> → { sha: "a1b2c3d…", content: "…" } # 2. Propose a rewrite (held in memory, not committed) POST /api/rewrite/<brand>/<slug> { "instruction": "Revise the valuation section for the updated range", "scope": "section" } → proposed text # 3. Human reviews before/after in Studio # 4. Accept (commits to git) POST /api/rewrite/<brand>/<slug>/accept { "content": "…revised text…", "baseSha": "a1b2c3d…", "instruction": "Revise the valuation section…", "model": "claude-sonnet-4-6" }
A raw PUT is fine for a new document or a verbatim mechanical edit. For "improve this," use propose → accept.

Status codes worth knowing

409Stale write, invalid transition, or restore no-op. Re-read, reconcile, don't retry blind.
422Vocabulary validation failed. diagnostics names the block.
502Render pipeline error. Not a content problem.

Path C — CLI

The CLI is useful for local authoring, validation before commit, and render preview. Requires pandoc 3.x, WeasyPrint 60+, Node 20+.

# Create a new document docgent new --brand vanaheim --type "Strategy Memo" --title "Q3 Review" # Validate against the vocabulary before committing docgent validate documents/vanaheim/q3-review/doc.md # Render to PDF locally docgent render documents/vanaheim/q3-review/doc.md

--renderer chrome swaps WeasyPrint for headless Chrome if you prefer.

Known gaps

  • No remote doctype/template listing. Use GET /api/docs/<brand> to see what doctypes exist — the values returned are the practical proxy.
  • No brand creation endpoint. Brands are provisioned manually today.
  • Tokens are issued by an operator, not self-serve. Self-serve issuance is on the roadmap.