Skip to main content
A workflow is plain JSON. You send it inside a session to POST /api/sessions, and the server validates and stores it.
The workflow schema is pre-beta and may change before v0.1.0.

Structure

Node options other than engine are abbreviated here. Each plugin defines its own options; see the plugin reference. Complete, runnable workflows are in the examples.

Session fields

See Sessions and workflows for the session-level fields (sessionId, name, description, initiator, projectPath, tags).

Workflow fields

Node fields

Plugin options

Everything in config except engine belongs to the plugin. Option values can be literals, or placeholders resolved just before the node runs; see Variables and expressions. To see the options a plugin accepts, ask the server:
The response lists every option with its type, default and description, and the output ports the plugin declares.

Engine options

The reserved engine object configures behaviour that the engine applies uniformly to any node: Alongside engine, a node’s timeoutSeconds sets its idle timeout.

Edge fields

Build one step by step

1

Pick a trigger

Use API_TRIGGER to start from a request with a payload, SCHEDULE_TRIGGER to start on a timer, or CONSTANT_SOURCE to emit fixed values.
2

Add processors

Chain the plugins that fetch, transform, route or decide. Add engine options where a node can fail.
3

End every branch with a terminal

Every path must reach a terminal. Send the error port of nodes with onError: ROUTE to a dead-letter terminal.
4

Validate

Check the definition before applying it with POST /api/sessions/validate. See Validation and versions.
5

Apply and start

POST /api/sessions, then POST /api/workflow/start.
You can also build workflows in the web UI, which renders a form from each plugin’s option list and shows a live preview of the graph.

Limits