Portal Community

Default: Full Response As Output

By default, the full deserialized response body is the node output:

// Service returns:
{
  "data": {
    "payslipId": "ps-2026-05",
    "grossPay": 5000.00,
    "netPay": 3850.00,
    "deductions": { "tax": 900, "pension": 250 }
  },
  "meta": { "generatedAt": "2026-05-25T10:00:00Z" }
}

// Node output (accessible as $output.calcPayslip):
{
  "data": { "payslipId": "ps-2026-05", "grossPay": 5000.00, ... },
  "meta": { "generatedAt": "..." }
}

// Downstream access:
$output.calcPayslip.data.netPay    // → 3850.00

Optional responseMap

Use responseMap to extract and rename specific fields for a cleaner output shape:

{
  "responseMap": {
    "payslipId": "$.data.payslipId",
    "netPay": "$.data.netPay",
    "grossPay": "$.data.grossPay",
    "taxAmount": "$.data.deductions.tax"
  }
}

// Resulting node output:
{
  "payslipId": "ps-2026-05",
  "netPay": 3850.00,
  "grossPay": 5000.00,
  "taxAmount": 900
}

// Cleaner downstream access:
$output.calcPayslip.netPay    // → 3850.00

The $ Prefix in responseMap

In responseMap value expressions, $. refers to the root of the service response body. This is the same convention as sub-workflow outputMap.

Type Coercion

If the service returns numbers as strings (a common issue with legacy services), use expression functions to coerce types:

{
  "responseMap": {
    "amount": "parseFloat($.data.amount)",
    "count":  "parseInt($.data.count)"
  }
}
Prefer responseMap in production. Mapping explicitly decouples downstream nodes from the service's internal response shape. If the service team adds fields or restructures the response, your downstream expressions don't break.