Input
workflow.entry Workflow v0.1.0 A named entry point into this workflow. A sibling workflow calls it by name and its payload arrives here.
Finding it in the library
Search the builder's node library for Input (it lives under Workflow). A single click opens the in-editor docs panel shown here — description, ports, and every property, without leaving the canvas. Double-click (or drag) to add it to the workflow.
Library capture pending — regenerate with npm run shots:nodes.
Wired up in the builder
Input in a real, runnable flow — captured live from the Studio editor, exactly as it looks on your canvas. This is the same workflow used for the example input & output below.
Canvas capture pending — regenerate with npm run shots:nodes.
How it’s configured
The node’s settings as the builder shows them — every field laid out with real values. In the Studio these are edited on the node: click the chevron on the divider under its ports to open them.
Config capture pending — regenerate with npm run shots:nodes. See the full property reference below.
Ports
This is a trigger — it starts runs and takes no input wire.
Ports are the node’s contract with its neighbours. In the editor a port label renders bold when wired and italic when optional; ◈ ports accept attachment carriers rather than data wires.
| Direction | Port | Label | What flows through it |
|---|---|---|---|
| Output | output | Payload |
How data flows through it
As a trigger, Input starts runs — it takes no input wire. What it emits is
the request wrapper: the event’s body becomes the payload, and the wrapper
carries the event metadata around it (for an HTTP-style trigger that’s
headers.*, request.method, request.path and
query). Downstream nodes consume the content — the wrapper is unwrapped
at each node boundary, and expression roots like {{ headers.x }} still
resolve against the wrapper when you need the metadata. See
Runs & run data for the envelope model.
Expressions in the config
String-typed properties accept {{ }} expressions evaluated against the
incoming item at run time — e.g. {{ $json.customer.email }}. On this node
that’s entry. JSON- and code-typed fields never interpolate — they are passed through literally.
Build it with AI
Every node in this reference is reachable through Flowdrome’s
AI Copilot and the
MCP tools — say what you want, and the graph surgery
happens server-side. Node types resolve fuzzily, so the catalog label
(Input) works as well as the exact type id (workflow.entry).
In the Copilot panel (or any connected AI):
create a workflow that starts with input and logs the result As a step in a create_chain_workflow call:
{"type":"Input","config":{}} Raw MCP call — add this node to a workflow with add_node
curl -s -X POST http://localhost:4800/mcp -H "content-type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "add_node", "arguments": { "workflowId": "<id>", "type": "Input" } } }' Example input & output
Captured from a real test run of the workflow above — this is what the Runs view shows after pressing Test workflow.
A sibling called this workflow at entry "main"; its payload arrives here.
Input — what the node received
{
"kind": "json",
"contentType": "application/json",
"payload": {
"ticket": "T-4821",
"customer": "ada"
},
"body": {
"ticket": "T-4821",
"customer": "ada"
}
} Output — what the node produced
{
"kind": "json",
"contentType": "application/json",
"payload": {
"ticket": "T-4821",
"customer": "ada"
},
"body": {
"ticket": "T-4821",
"customer": "ada"
}
} Property reference
Every setting, with its type and default — the same fields shown configured above.
| Property | Type | Default | Description |
|---|---|---|---|
Entry nameentry | string | "main" | What callers ask for. A workflow can have several entries — createTicket and closeTicket can start different parts of the same graph. |
Related nodes
The rest of the Workflow group — the same folder you’d scan in the editor’s library.
This page is generated from the node registry by gen-node-docs.mjs on every
site build — ports, properties, defaults and visibility rules cannot drift from the code.
The screenshots and example data are captured from a live Flowdrome by
npm run shots:nodes and npm run gen:examples.