Hidden inputs
Alongside the inputs declared in the schema, which create corresponding inputs or widgets on the client-side, custom nodes can request certain information from the server through hidden inputs. Hidden inputs are not visible in the UI. In the V3 schema, hidden inputs are requested by passing a list ofio.Hidden enum values to the hidden
parameter of the schema. During execution, the values are available on the node class as cls.hidden, so
an execute method can read them by name:
UNIQUE_ID
io.Hidden.unique_id provides the unique identifier of the node, and matches the id property of the
node on the client side. It is commonly used in client-server communications (see
messages).
PROMPT
io.Hidden.prompt provides the complete prompt sent by the client to the server. See
the prompt object for a full description.
EXTRA_PNGINFO
io.Hidden.extra_pnginfo provides a dictionary that will be copied into the metadata of any .png files
saved. Custom nodes can store additional information in this dictionary for saving (or as a way to
communicate with a downstream node).
DYNPROMPT
io.Hidden.dynprompt provides an instance of comfy_execution.graph.DynamicPrompt. It differs from
PROMPT in that it may mutate during the course of execution in response to Node Expansion.
Flexible inputs
Custom datatypes
If you want to pass data between your own custom nodes, you may find it helpful to define a custom datatype. This is (almost) as simple as just choosing a name for the datatype, which should be a unique string in upper case, such asCHEESE.
Create the type with the io.Custom helper (or the @io.comfytype decorator for a full class
definition), then use it for inputs and outputs. The Comfy client will only allow CHEESE outputs to
connect to a CHEESE input. A CHEESE value can be any Python object.
CHEESE, it can’t display a widget for it. Custom
datatype inputs are therefore socket inputs: they must be connected to an upstream node, and the widget
conversion options (force_input and socketless) don’t apply to them. If you want a widget fallback for
your custom type, you need to define a custom widget for it, which is a topic for another day.
Wildcard inputs
The frontend allows* to indicate that an input can be connected to any source. In the V3 schema,
io.AnyType provides this wildcard type directly:
io.AnyType, type validation accepts any input, so the legacy V1 workaround (adding an
input_types argument to VALIDATE_INPUTS in order to skip backend validation) is not needed. It’s up to
the node to make sense of the data that is passed.
Dynamically created inputs
If inputs are dynamically created on the client side, they can’t be defined in the Python source code. The V3 schema handles this with theaccept_all_inputs flag. When it is True, all inputs from the
prompt that are not defined in the schema are passed through to execute as keyword arguments:
accept_all_inputs
only affects the inputs that are not declared.