HTTP API

The server is a thin HTTP layer over the shared application core. The run handler spawns the same executor the desktop and CLI use, forwarding execution events to a server-sent-events stream.

Routes

Method	Path	Returns
GET	/ (+ assets)	The shared frontend SPA
GET	/health	ok
GET	/api/templates	Saved templates (JSON)
GET	/api/nodes	Node catalog (JSON)
GET	/api/history	Recent runs (JSON)
GET / POST	/api/run	Run a flow (graph, template, or dsl); streams execution events as SSE
GET	/api/llm/status	Managed local-model server status (JSON)
POST	/api/llm/start	Provision + launch (fetches the engine on first use)
POST	/api/llm/stop	Stop the managed model server
POST	/api/invoke	Generic command bridge {command, args} backing the host facade

Running a flow

/api/run accepts three input shapes:

• {"graph": {...}} is the desktop run shape. The browser host uses it to run an in-memory canvas graph.
• {"template": "<slug>"} runs a saved template.
• {"dsl": "<flow dsl>"} runs raw DSL text.

You can POST a JSON body, or use ?template= or ?dsl= on GET for a browser EventSource. The response is text/event-stream. Each data: frame is one kind-tagged execution event. These are the same events the desktop renders and the CLI emits as NDJSON. Runs are recorded to the shared SQLite history and tagged with the flow name.

curl -N localhost:8787/api/run -H 'content-type: application/json' \
  -d '{"template":"hello-flow"}'

The invoke bridge

/api/invoke takes {command, args} and backs the host facade’s generic invoke. It uses the same command names the desktop exposes. Each wired command returns the core type verbatim, matching the desktop. Unwired commands return 501, and parity grows incrementally. This is how the browser edition reaches settings, hubs, schedules, and the rest of the command surface without a desktop shell.

Related

• Deploy and authentication
• CI integration is the NDJSON counterpart of the SSE stream.