Create a Custom Node

Creating a strong custom node is partly a technical job and partly a product-design job.

You are not only building internal logic. You are also designing the setup experience other people will depend on.

The Custom Node Canvas

1. Open the Custom Nodes section in Studio.
2. Create a new custom node.
3. Give it a clear name and description.
4. Decide what problem it solves before you build the internal flow.

The best names describe the outcome, not the implementation. "Slack Alert" is better than "Webhook Wrapper". "Server Event Mapper" is better than "HTTP Flow 3".

Step 1: Define Input Properties

Start by defining the inputs other people should configure.

This is the contract of the node. If the contract is confusing, the node will feel confusing even if the internal logic is excellent.

For example, if you are building a Slack notification node, your properties might include:

• webhookUrl
• channelName
• messagePayload

Good input design usually means:

• grouping related fields into sections
• using clear labels and helper text
• making required fields obvious
• hiding advanced behavior unless it really needs to be configurable

Step 2: Build the Internal Logic

Inside the custom node's private canvas, you build the internal flow exactly as you would in an application flow.

The main difference is that the flow starts from Custom Node Input instead of a browser trigger.

Use the configured input values throughout the internal flow. For example:

• {{ $input.webhookUrl }}
• {{ $input.event_name }}
• {{ $input.pixel_id }}

Design Guidelines for Good Custom Nodes

• Keep the public surface small. Expose only what callers genuinely need.
• Normalize and validate early in the internal flow.
• Prefer built-in nodes before reaching for custom code.
• Use clear action modes when one node supports multiple jobs, such as load and track.
• Design with future maintenance in mind. Someone else should be able to understand the node six months later.

Step 3: Publish

Publish the custom node when its interface and behavior are ready.

After publishing, it becomes available in the workspace for application flows to use.

Before you publish, test the internal flow the same way you would test any important logic: verify the inputs, confirm the output shape, and make sure failures are understandable rather than silent.