Original explainer
n8n structured output: from JSON examples to field checks
Configure Structured Output Parser and check mandatory fields, JSON Schema and expression behavior with multiple inputs.
When model output feeds another node, its field structure needs an explicit contract. Structured Output Parser returns fields based on JSON Schema, which constrains format rather than proving classification accuracy. The expected output here is a two-field message classification structure and repeatable structural and semantic checks. You need an n8n AI workflow that supports connecting an output parser.
Action and checking sequence
Define fields
Start with category and reason required by the consuming node.[1]
Choose a schema
Choose example generation or a manual schema based on types and required fields.[1]
Check separately
Check fields and types first, then whether the reason follows from the input.[1]
Start with a minimal JSON example
Original exercise input: “The task failed; please help diagnose the error.” Write the intended shape as {"category":"support","reason":"Requests help diagnosing a failure"}. Select Generate from JSON Example in Schema Type and enter the object. The documentation says this uses property names and types, ignores actual values and makes every example field mandatory. The example alone does not restrict category to support.[1]
When to use a manual schema
Use Define using JSON Schema when you need an explicit category set. Define enum, required and other fields from your own data contract: category might allow support, feedback and other, while reason is a string. The documentation says $ref is unsupported, so keep the required definitions in the schema itself rather than expecting a downstream node to repair unresolved references.[1]
Watch sub-node expressions with multiple inputs
The documentation highlights that root-node expressions can resolve per item, while expressions in sub-nodes always resolve to the first item. If a sub-node parameter uses {{ $json.name }}, do not assume it changes for every message. Inspect the actual data path with two visibly different exercise inputs. If rules vary per item, handle rule selection in upstream logic that processes items individually and verify the connection.[1]
Separate structural and semantic acceptance
- Structural check: confirm category and reason exist, match the expected types and follow your policy for extra fields.
- Semantic check: troubleshooting belongs to support, a suggestion to feedback, and uncertainty follows your defined fallback.
- Failure check: record missing fields, invalid categories and empty input separately; schema validity is not business accuracy.
The JSON example was parsed locally and the design checked against the official parameter descriptions. n8n login, node execution, model calls and accuracy measurement were not performed. Categories and expected exercise results are original acceptance criteria; adapt them to your own messages.[1]
Article sources
Original editorial content; official descriptions and checking suggestions are distinguished.