Integration guide

Three ways in.

Existing authorised users only. Public signup, trials and checkout are not available yet. Before installing, you need OpenClaw already installed (for Path A), a provisioned brand and a per-brand token issued by your existing administrator. Application sign-in requires a Google account on that brand’s allowlist. This reference preserves the existing connection instructions; it is not a verified fresh-install self-service journey. Read the access and troubleshooting guide or sign in with existing access.

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

Path A

Agent skill

Connection reference for existing configured users. Fresh installation has not been verified.

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 documented install flow describes requesting a per-brand token, checking it, saving it, and patching 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

Documented token check for an existing configured connection; this is not fresh-install verification:

GET /api/status/<brand>/__token-check__ 404 → token valid, brand reachable 401 → wrong token or wrong brand

Do not bypass authentication. Fail-closed behaviour has not been independently verified for a fresh installation. Stop on authentication errors and ask your existing administrator; do not borrow another brand’s token or route around authentication.

Path B — REST API

Agents use a per-brand bearer token for the permitted document operations below. Status reads allow agents; status transitions require an authenticated human session. Agent bearer tokens cannot change status.

What	Call
List a brand's documents	`GET /api/docs/<brand>?status=&doctype=`
Read (any version)	`GET /api/doc/<brand>/<slug>?ref=<sha>`
Create	`PUT /api/doc/<brand>/<slug>` — no `baseSha`
Update	`PUT /api/doc/<brand>/<slug>` — with `baseSha`
Propose a rewrite	`POST /api/rewrite/<brand>/<slug>`
Accept a proposal	`POST /api/rewrite/<brand>/<slug>/accept`
Semantic diff	`GET /api/diff/<brand>/<slug>?base=&head=`
Render committed PDF	`GET /api/render/<brand>/<slug>?ref=`
Preview unsaved	`POST /api/preview/<brand>/<slug>`
Read status (agents allowed)	`GET /api/status/<brand>/<slug>`
Status transitions (human-only)	`POST /api/status/<brand>/<slug>` — authenticated human session required, not an agent bearer token.
Restore old version	`POST /api/restore/<brand>/<slug>`
Brand config / assets	`GET` · `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. The proposal is held in memory until accepted. Accepting a proposal commits content; it does not record human review or approve or release the document. Have a human inspect the changes; only an authenticated human session can change review status.

# 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

409	Stale write, invalid transition, or restore no-op. Re-read, reconcile, don't retry blind.
422	Vocabulary validation failed. `diagnostics` names the block.
502	Render 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.