Return Output Values From a Processing Module

Module outputs let a processing module return values to whatever triggered it, e.g., another module or an external system calling the module's API. Think of them as the module's return values: the counterpart to start parameters, which are the module's inputs.

What outputs look like

Outputs are a typed list of named values. Each output has:

• A name – how the caller references the returned value.
• A type – such as text, number, date, or email.
• An optional description.

On the module's result node, you map each declared output to a value from the module's local variables. When the module finishes, the caller receives the outputs as a structured object.

Configure outputs

1. Open a processing module in the editor.
2. On the API node sidebar, you will see an OUTPUTS section below the INPUTS (start parameters).
3. Click + Add output and give it a name and type.
4. Open the Result node and map each output to the variable that should be returned.

If an output is left unmapped, the caller receives null for that field.

Consume outputs

From another module

When you add a Batch process action that calls a processing module, the outputs appear as variables you can reference in the calling module. They become available after the node runs.

From the API

The module's API response contains the outputs under an outputs key, shaped according to the output schema you defined:

{
  "outputs": {
    "riskScore": 42,
    "decision": "approve",
    "contactEmail": "reviewer@example.com",
    "reviewedOn": "2026-04-17"
  }
}

Change outputs safely

Adding a new output is safe: existing callers simply ignore fields they do not know about.

The editor does not rewrite caller references for you, so you need to update them manually. For all breaking changes, publish a new version of the module and coordinate with callers before pointing them at the new version.

Outputs and module type conversions

Module outputs are exclusive to processing modules. If you convert a module to a different type, outputs are affected:

• Processing → Input: Outputs are removed.
• Processing → Scheduled: Outputs are removed.
• Input → Processing: You start with no outputs – add them as needed.
• Scheduled → Processing: You start with no outputs – add them as needed.

The conversion dialog warns you before any outputs are removed. For more on converting between types, see Module Types: Input, Processing, and Scheduled.

Best practices

• Name outputs by what they mean, not how they are computed. For example, riskScore is clearer than computedRisk.
• Keep the output surface stable. Each caller is a consumer of your module's contract. Changing names or types costs them work.

Occasionally asked questions

Related articles

• Module Types: Input, Processing, and Scheduled
• Introduction to Modules
• Make a Module Available via API Key Only