type. Yukta ships 34 of them in three roles: triggers start a workflow, processors transform, route and call out, and terminals end a branch.
This page lists every type at a glance. Each group has its own page with every option, the output ports and a JSON example.
The plugin set and the options of each plugin are pre-beta (
0.0.1-SNAPSHOT) and may change before v0.1.0.Type strings
Use a type string exactly as written below. Lookup is exact and case-sensitive, sobranch and Branch are not found. Almost every type is upper case with underscores. CONTENT-FILTER is the one type that uses a hyphen.
Triggers
A trigger has no input. It produces the first message of a run. See Triggers.Processors
Processors read messages from their parents and emit messages on named output ports.Routing and flow
See Routing and flow.Transform
See Transform.External I/O
See External I/O.AI
See AI plugins.Decisions
See Decision plugins.Terminals
A terminal consumes messages and has no output ports. See Terminals.Options every node accepts
Besides the options of its plugin, a node’sconfig can carry:
timeoutSeconds: the node’s idle timeout in seconds. Without it the node uses the default timeout of its plugin, which is 30 seconds unless the plugin page says otherwise. See Time limits.engine: the reserved engine policy object (retry, error routing, deadline, edge buffer, placement). See Failure handling.
${...} variables, its description says so; see Variables and expressions for the syntax. Options that take an expression use the expression language described on that page.
Choosing which plugins a build includes
Triggers, terminals and the routing, transform and flow processors (BRANCH, FILTER, SPLITTER, AGGREGATE, RECIPIENT_LIST, DELAY, LOOP_PREDICATE, LOOP_STREAM, SUB_WORKFLOW, WAIT_FOR_SIGNAL, MAPPER, VALIDATE, CONTENT-FILTER, KV_STORE) are always part of the server. The rest are optional and chosen when the server is built, with the build property yukta.plugins:
An unknown module name stops the build. The modules and the types they provide:
Leaving a module out removes its capability from the server entirely. A deployment that does not need to run commands, SQL or scripts can leave those modules out.
When a type is not installed
A workflow that uses a type the server does not have is rejected when it is validated, with the messagePlugin not found for type: <TYPE>, and its node never runs. MAPPER in SCRIPT mode is rejected the same way, with a message that names script-js, when that module is missing. See Validation and versions.
To see what a running server has, list its plugins:
type with its category (TRIGGER, PROCESSOR or TERMINAL). The web UI plugin catalogue and the MCP tools list_plugins and get_plugin_details show the same information.
Reading a plugin’s option schema
GET /api/plugins/{type} describes one installed plugin. It answers 404 when the type is not installed.
A plugin with no configuration, such as
API_TRIGGER or CONSOLE_TERMINAL, returns an empty configSchema.