Inputs and Outputs
Every Blueprint has a Data Contract — the inputs it expects, the outputs it returns, and any local variables it uses internally. You configure these in the Data panel on the left side of the editor.
Inputs
Inputs are the values your Blueprint receives when it runs. Each input has:- Name — the identifier used to reference this value in your logic (e.g.,
cartValue,deliveryDistance) - Type — what kind of data it holds:
string,number,boolean,date, orenum - Description — explains what the value represents
- Required — whether the input must be provided or is optional
- Multiple — whether the input accepts a list of values instead of a single value
List inputs
When you check the Multiple option, the input accepts a list of values. This is useful when your Blueprint needs to process multiple items — like a list of order amounts or customer names. Use Loop elements to iterate over list inputs.Outputs
Outputs are the values your Blueprint returns when it finishes. They have the same configuration options as inputs: name, type, description, required, and multiple.
Local variables
Local variables are internal to your Blueprint — they’re not visible to callers. Use them for intermediate calculations, counters, or temporary values that don’t need to be part of the public Data Contract. Click the Locals section in the Data panel to see and manage local variables.The Data Contract in context
The Data Contract serves different purposes depending on how your Blueprint is used:| Context | How the Data Contract is used |
|---|---|
| Testing | The Run panel shows input fields based on your inputs, and displays output values after execution |
| Call nodes | When another Blueprint calls yours, it maps values to your inputs and captures your outputs |
| REST API | API callers send inputs as JSON and receive outputs in the response |
| MCP | AI assistants use the Data Contract to understand what your Blueprint does and how to call it |
| Specification view | The Data Contract appears as a readable section at the top of the document |
Tips
- Use descriptive names —
cartValueis better thanval1 - Write descriptions as if explaining to someone who’s never seen your Blueprint
- Only mark inputs as required if the Blueprint truly cannot function without them
- Keep the Data Contract focused — if your Blueprint has many inputs, consider splitting it into smaller Blueprints connected with Call nodes
What to do next
- Controlling the Flow — learn about the elements that use your inputs and produce outputs
- Test your Blueprint — run your Blueprint with test inputs
- Specification view — see your Data Contract as a readable document