All guides

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.

AI Nav CityWritten / Updated Sources checked

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

  1. Define fields

    Start with category and reason required by the consuming node.[1]

  2. Choose a schema

    Choose example generation or a manual schema based on types and required fields.[1]

  3. Check separately

    Check fields and types first, then whether the reason follows from the input.[1]

Check the input, action and result at each step; see the final section for execution scope.

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.

[1]

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.

  1. n8n · Official sources
    View details