Node types and code languages

A node on the canvas is a block in workflow YAML. Workflows are Pro and must be enabled under Settings → Experimental → Workflows. Choose the smallest block that does the job: an HTTP block for a saved endpoint, an MCP block for a saved tool, and code for a transformation that needs programming. Use AI when the task needs model judgement rather than a fixed rule.

Node types at a glance link

The editor currently offers eight types; the runner accepts the seven types other than git. A trigger starts a workflow and is configured on Triggers. It is not another runnable block type.

Code and Code file link

Code stores source under body. Code file reads the source at path; a relative path is resolved against the workflow’s folder. Both receive input and publish output in the same way.

Code file infers its language from the file extension when language is omitted. Set language explicitly for an unusual extension. Its args value is split on whitespace; shell quoting does not group arguments containing spaces. Use the input file for structured values instead.

The runner copies source into a build directory and executes it with the run’s files/ directory as the working directory. A Code file is not a project launcher: it does not run cargo, npm install, or a .csproj. Do not assume relative imports or companion files will resolve beside the original source. Use explicit paths or a self-contained file.

All supported code languages link

These seven language values apply to both Code and Code file. The runtime must be installed on the computer running Termorq; these interpreters and compilers are not bundled with the workflow.

C# uses .NET file-based apps, so no project file is needed for the cookbook’s BCL-only example. Rust runs through rustc directly, so a Cargo dependency such as serde_json is not automatically available. The Rust cookbook example uses only the standard library.

Native Node.js TypeScript execution strips erasable type syntax and does not type-check the program or apply tsconfig.json. Keep snippets within that subset; see Node.js TypeScript support. Termorq prefers native execution when it is available, even if tsx is also installed.

What TERMORQ_INPUT is for link

TERMORQ_INPUT is an environment variable containing a file path. It does not contain the JSON itself. Read the file at that path, then parse its content when your block expects JSON. Standard input is closed; reading from stdin is not the workflow input mechanism.

The file is the language-neutral handoff from the workflow engine to your program. It preserves structured values without inserting them into executable source or shell arguments. Code bodies are not template-expanded: putting {{ steps.lookup.total }} inside source does not pass that value to your program. Declare it in uses and read it from the input file instead.

During a full workflow run, uses declares the values a code block needs. Termorq resolves those paths and writes a temporary JSON object containing only those values, preserving their nesting:

uses:
  - trigger.text
  - steps.lookup.total

For example, if those values are available, the file contains:

{"trigger":{"text":"Hello"},"steps":{"lookup":{"total":2}}}

The code reads trigger.text and steps.lookup.total from that object. It does not read a flattened text or total property. If uses is empty, a full run does not supply an input file. If a listed value is unavailable, the block fails before its code starts. Listing a path does not create a default value for it.

The file has mode 0600 on Unix and is removed when the code block finishes. Treat its path as temporary. Keep credentials out of input_sample and diagnostic output. The code runs with the application’s user permissions; choosing only the required uses values is useful data minimisation, not a code sandbox.

Execute step and input_sample link

Execute step runs only the selected inline Code block. It supplies Step input directly to the file, rather than constructing the file from uses:

• JSON objects, arrays, numbers, booleans, and null are encoded as JSON. To reproduce a full run, enter the same nested object shape shown above.
• Plain text, including a JSON string value, is written as raw text. Read it as text instead of passing it to a JSON parser. The execution scope also exposes it as inputs.text and trigger.text.
• Blank input produces {}.

Input beginning with { or [ is treated as attempted JSON and rejected if it is malformed.

The Code block’s input_sample saves this editor sample in YAML. Save the workflow to persist it. It is a test fixture, not a default input for triggers or full workflow runs. A successful isolated test does not prove that the real trigger supplies every path in uses.

Publishing code output link

Write diagnostic messages to stderr and write the result to stdout. With custom output properties declared under outputs, the last non-empty stdout line must be one JSON object. Keep that object on one line, even if earlier diagnostic lines exist.

outputs:
  type: object
  properties:
    message:
      type: string

The code must finish with output such as {"message":"Hello"}. A following block can declare uses: [steps.echo.message], where echo is the producer’s block ID. The runner checks declared custom properties for presence and the declared string, number, boolean, object, or array type. Missing properties, mismatched types, or a non-object final line fail the block.

Without custom output declarations, code may print plain text. The runner records its raw stdout as text, its exit code as exit, and successful execution as status: ok. A non-zero exit fails the block. Use a custom name such as message for structured business data; text is reserved for raw stdout. Do not treat outputs as a filename or expect Termorq to parse every stdout line.

TERMORQ_OUTPUT is a different variable: it points to the run’s files/ directory for artifacts. Writing a file there does not publish a JSON property. TERMORQ_FOLDER identifies the configured workflow folder; it is not the process’s working directory.

HTTP endpoint link

Use a saved endpoint for a real network request. The block reuses its API connection and credentials; method and body can supply workflow-specific values. A direct url is currently accepted by the runner only for mock:// examples, not arbitrary network URLs.

HTTP publishes a numeric status and a body string. The recorded body string is capped at 4,096 bytes. When the response is a JSON object, its top-level properties are also available; declare the properties downstream blocks need. Use code to serialise a JSON request body before inserting it into the HTTP block, so quotes and newlines in user input remain valid JSON.

MCP tool link

Choose a saved server and tool. Termorq reuses the server’s transport and authentication settings and connects for the call. arguments must resolve to JSON matching the tool’s input contract.

MCP publishes status: ok, a text representation, and the top-level properties of the MCP result. A result may contain content or structuredContent; JSON inside a content[].text string is not automatically flattened into workflow properties. Inspect that tool’s result and declare the fields you need. The cookbook shows how to serialise arguments safely.

AI link

Choose a saved model connection, set system and prompt, and optionally set max_tokens. Prompts can include earlier workflow properties. Results include text and model. Open AI editor runs this block in isolation with editable JSON or text input and shows the model response, errors, and published outputs. Its input_sample is saved in YAML when you save the workflow, but only supplies the editor’s sample input; it is not used by triggers or full runs. In the editor, JSON object fields are available as inputs.<name>, nested trigger values as trigger.<name>, and plain text as trigger.text and inputs.text.

If you declare another output property, such as summary, Termorq asks the model to end its reply with one JSON object and reads that final line. A reply without that object fails. Validate model-produced data before using it for a consequential action; use Code or Decision for fixed rules and validation.

Decision link

The first true when branch wins; else: true supplies the required fallback. goto names a block ID. Conditions compare workflow values; they are not Bash, JavaScript, or C# expressions. Non-selected targets are skipped. Set the branch blocks’ then values to the shared continuation when both routes should converge.

Loop link

for_each walks an array, repeat runs a fixed count, and while evaluates a workflow condition before each pass. Put runnable child blocks under body. Code in that body can request the loop context through uses.

The default max is 20; the ceiling is 100. A run allows at most 100 loop passes in total, and loops can nest two deep. Keep remote calls bounded. The loop publishes results, an array with each pass’s child outputs keyed by child block ID, plus status and exit.

Git file availability link

The editor includes Git file fields for a public repository, ref, path, and inferred code language. The backend currently rejects kind: git, so verification in the editor does not make the block executable. To run that source today, check out and review the desired revision locally, then use Code file. It supports the seven languages listed above.

Related pages link

• Code and block examples
• Build a workflow
• Triggers, runs, and notices
• termorq-cli workflow