Hidden and Flexible inputs (V3)

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 of io.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:

from comfy_api.latest import io

class MyNode(io.ComfyNode):
    @classmethod
    def define_schema(cls) -> io.Schema:
        return io.Schema(
            node_id="MyNode",
            inputs=[io.String.Input("text")],
            outputs=[io.String.Output()],
            hidden=[
                io.Hidden.unique_id,
                io.Hidden.prompt,
                io.Hidden.extra_pnginfo,
            ],
        )

    @classmethod
    def execute(cls, text) -> io.NodeOutput:
        # hidden values are accessed via cls.hidden
        print(cls.hidden.unique_id)
        print(cls.hidden.prompt)
        print(cls.hidden.extra_pnginfo)
        return io.NodeOutput(text)

Available hidden values (see the V3 Migration guide for the full list):

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).

Note that if Comfy is started with the disable_metadata option, this data won’t be saved.

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.

DYNPROMPT should only be used for advanced cases (like implementing loops in custom nodes).

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 as CHEESE. 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.

from comfy_api.latest import io

# Create the custom type once, then reuse it
Cheese = io.Custom("CHEESE")

class CheeseNode(io.ComfyNode):
    @classmethod
    def define_schema(cls) -> io.Schema:
        return io.Schema(
            node_id="CheeseNode",
            inputs=[Cheese.Input("my_cheese")],
            outputs=[Cheese.Output()],
        )

Because the Comfy client doesn’t know anything about 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:

class AnyNode(io.ComfyNode):
    @classmethod
    def define_schema(cls) -> io.Schema:
        return io.Schema(
            node_id="AnyNode",
            inputs=[
                io.AnyType.Input("anything"),
            ],
            outputs=[io.AnyType.Output()],
        )

With 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 the accept_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:

class FlexibleNode(io.ComfyNode):
    @classmethod
    def define_schema(cls) -> io.Schema:
        return io.Schema(
            node_id="FlexibleNode",
            inputs=[
                # inputs that are always present can still be declared here
            ],
            outputs=[io.Image.Output()],
            accept_all_inputs=True,
        )

    @classmethod
    def execute(cls, **kwargs) -> io.NodeOutput:
        # the dynamically created input data will be in the keyword arguments
        ...

Note that inputs declared in the schema are still validated and dispatched normally; accept_all_inputs only affects the inputs that are not declared.

Build Custom Nodes

Package & Publish

Hidden and Flexible inputs (V3)

Hidden inputs

UNIQUE_ID

PROMPT

EXTRA_PNGINFO

DYNPROMPT

Flexible inputs

Custom datatypes

Wildcard inputs

Dynamically created inputs

​Hidden inputs

​UNIQUE_ID

​PROMPT

​EXTRA_PNGINFO

​DYNPROMPT

​Flexible inputs

​Custom datatypes

​Wildcard inputs

​Dynamically created inputs

Hidden inputs

UNIQUE_ID

PROMPT

EXTRA_PNGINFO

DYNPROMPT

Flexible inputs

Custom datatypes

Wildcard inputs

Dynamically created inputs