Flow Studio
Response Mapping
How the service response body becomes node output and how to use the optional responseMap to reshape it for downstream consumption.
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.