Skip to main content
PATCH
Edit files in a context document tree

Authorizations

Authorization
string
header
required

API Key or JWT User Token. If using an API Key, set the X-As-User header to act as a specific user. A JWT User Token is always scoped to a specific user.

Path Parameters

tree_id
string
required

Body

application/json

Request body for editing files in a tree.

All three edit kinds persist to the tree_edits table so they survive subsequent regens. Editable when status is COMPLETED or PUBLISHED; files / renames / deletions can all be sent in a single call.

files
Files · object

Map of file path → new content (content edits).

renames
Renames · object

Map of old path → new path (rename edits).

deletions
string[]

List of file paths to soft-delete (sticky until cleared).

until_next_regen
boolean
default:false

When true, the CONTENT edits in this request auto-clear after the next successful tree regeneration instead of pinning the file indefinitely. Rename/delete/add edits are unaffected.

additions
Additions · object

Map of file path → initial content for user-declared files at paths the LLM doesn't produce. Sticky until cleared.

Response

Successful Response

tree_id
string
required
status
string
required
version
integer
required
files
TreeFile · object[] | null
required
error
string | null
required
created_at
string<date-time>
required
completed_at
string<date-time> | null
required
meta
Meta · object
required
generating
TreeGenerating · object | null

Sidecar describing an in-flight (or just-failed) regeneration.

Present only on the dashboard path (include_published=true) when a newer PROCESSING/FAILED row exists behind the served ready tree — the served body stays the last COMPLETED/PUBLISHED tree so the brain never blanks out mid-regen, and this block is how the UI knows to show a progress banner.