The UI API exposes direct graph operations intended for interactive editing, migrations, and tooling. Unlike /v1, it does not enforce ingest
placement semantics.
Endpoint groups
| Group | Endpoints | Notes |
|---|---|---|
| Model and graph payload | GET /api/ui/datamodel, GET /api/ui/graph |
Model diagram source and graph snapshot for visual clients. |
| Topic CRUD | POST/GET/PATCH/DELETE /api/ui/topics... |
Create, list, fetch, patch, and delete topics directly. |
| Relationships | POST/DELETE /api/ui/topics/{id}/relationships |
Direct RELATED management. |
| Fields | POST/GET/DELETE /api/ui/topics/{id}/fields... |
Field history append/read/delete and ref updates. |
Graph snapshot details
GET /api/ui/graph returns:
nodes[]with topic metadata, summarized fields, andcommunitycluster id.edges[]with bothrelatedandfield_refedge types.
Community ids are computed by blending structural links (RELATED + refs) with embedding-similarity neighborhoods.
Field operations behavior
POST /fieldsappends history and can create missing fields.GET /fields/{name}can return full history (with_history=true) or current snapshot only.PUT /fields/{name}/refsets or clearsref_topic_id.- Field operations update topic salience via field-average synchronization.
Low-level flow diagram
UI client request -> /api/ui handler
-> GraphStore direct method call
-> Kuzu update/read
-> optional graph snapshot normalization
-> JSON response (no Executor placement layer)
When to use this surface
- Interactive editors that need immediate, precise control over graph shape.
- Migration and repair tooling.
- Debugging or inspection scripts that need direct topic/field endpoints.
For product-facing ingestion/query behavior, prefer
/v1. The UI API intentionally exposes lower-level primitives and fewer guardrails.