Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, the validation loop process, or aut

n8n Validation Expert Expert guide for interpreting and fixing n8n validation errors. Validation Philosophy Validate early, validate often Validation is typically iterative: Expect validation feedback loops Usually 2 3 validate → fix cycles Average: 23s thinking about errors, 58s fixing them Key insight : Validation is an iterative process, not one shot! Error Severity Levels 1. Errors (Must Fix) Blocks workflow execution Must be resolved before activation Types : missing required Required field not provided invalid value Value doesn't match allowed options type mismatch Wrong data type (string instead of number) invalid reference Referenced node doesn't exist invalid expression Expression syntax error Example : 2. Warnings (Should Fix) Doesn't block execution Workflow can be activated but may have issues Types : best practice Recommended but not required — surfaces under ai friendly / strict only deprecated Using old API/feature — surfaces under every profile security Hardcoded secrets, unauthenticated webhooks — surfaces under every profile performance Potential performance issue — advisory, ai friendly / strict Example (best practice — appears under ai friendly / strict ): 3. Suggestions (Optional) Nice to have Improvements that could enhance workflow Types : optimization Could be more efficient alternative Better way to achieve same result The Validation Loop Pattern from Telemetry 7,841 occurrences of this pattern: Example This is normal! Don't be discouraged by multiple iterations. Validation Profiles The four profiles are cumulative (n8n mcp ≥ 2.63.0): each surfaces everything the lower one does, plus more. The dividing line is best practice advisories — minimal and runtime withhold them; ai friendly and strict add them. Errors are the same across every profile except that minimal skips a few config level checks (e.g. enum validation of an explicit operation ). Security and deprecation warnings surface under every profile. minimal Use when : Quick structural checks while wiring a workflow together. Surfaces : hard errors that would stop execution (missing required fields, empty code, broken connections). Skips enum checks and all advisories. Fastest and most permissive. runtime (RECOMMENDED default) Use when : Ongoing validation as you build; the everyday profile. Surfaces : errors (required fields, value types, allowed values, dependencies, broken references) plus security and deprecation warnings. No best practice advisories. Balanced — catches everything that breaks, stays quiet about style. ai friendly Use when : You want the best practice advice before deploying. Surfaces : everything runtime does, plus best practice advisories — per node "without error handling" suggestions, "webhook should always send a response", rate limit notes, outdated typeVersion suggestions, cachedResultName and long chain hints. Note : ai friendly is stricter than runtime , not looser. (Older docs described it as reducing false positives — that was true only while profile gating was broken; it is fixed now.) strict Use when : Hardening a production critical workflow. Surfaces : everything ai friendly does, plus leftover property checks ("property 'X' won't be used — not visible with current settings"). Maximum lint. With the false positives fixed at the source, its warnings are advice to weigh, not noise to fight. Common Error Types Five core error types, in rough order of frequency: missing required — a required field isn't provided. Use get node to see required fields, then add it. invalid value — value doesn't match allowed options (enums are case sensitive). Check the error's allowed list or get node . type mismatch — wrong data type (string "100" vs number 100 ). Convert to the expected type. invalid expression — expression syntax error (missing {{}} , typos). See the n8n Expression Syntax skill. invalid reference — referenced node doesn't exist (renamed, deleted, or misspelled). Fix the name or cleanStaleConnections . A sixth class, patchNodeField errors (find not found, ambiguous match, invalid/unsafe regex), surfaces when a patchNodeField op fails during n8n update partial workflow — it's strict by design and errors rather than silently continuing. Every type above has worked examples (broken config → fix) plus the patchNodeField error cases and their fixes in [ERROR CATALOG.md](ERROR CATALOG.md) . Auto Sanitization System Automatically normalizes common operator structures on ANY workflow update — n8n create workflow , n8n update partial workflow , or any save. Trust it; don't hand fix these. What it normalizes on save : Binary operators (equals, notEquals, contains, notContains, greaterThan, lessThan, startsWith, endsWith) — removes a stray singleValue property. Unary operators (isEmpty, isNotEmpty, true, false) — adds singleValue: true . IF/Switch metadata — fills in conditions.options for IF v2.2+ and Switch v3.2+. Validation no longer errors on these shapes (n8n mcp ≥ 2.63.0). n8n derives unary ness from the operator name and defaults the conditions.options sub fields, so validate node / validate workflow accept a condition whether or not singleValue and the options metadata are present — the sanitizer just tidies the canonical form on save. (Older servers wrongly errored on the un normalized shape; if you see that, upgrade.) What still is a real error: a v1 shaped conditions object on a v2 node, an empty filter with no conditions, and legacy v1 operator names (e.g. smaller ) inside a v2 structure. What the sanitizer CANNOT fix (handle manually): broken connections to non existent nodes (use cleanStaleConnections ), branch count mismatches (add/remove connections or rules), and paradoxical corrupt states (may need manual DB intervention). Before/after examples and the full cannot fix detail are in [ERROR CATALOG.md](ERROR CATALOG.md) (Auto Sanitization sections). False Positives The validator overhaul (n8n mcp ≥ 2.63.0) removed the classic false positives — template literals inside expressions, optional chaining, omitted operation defaults, the Webhook → Respond to Webhook pattern, IF/Filter legacy shapes, and more no longer fire. There is no standing list of "known false positives to ignore." What remains are best practice advisories (surfaced only under ai friendly / strict ) that flag a real trade off but may be acceptable in your case. Not every advisory needs a fix — many are context dependent. Common ones and when each is acceptable vs. worth fixing: "...without error handling" — OK for dev/testing and non critical notifications; fix for production handling important data. (Never a hard error — style doesn't block execution.) "No retry logic" — OK for idempotent ops, APIs with their own retry, manual triggers; fix for flaky external services and production automation. "...rate limits and transient failures" — OK for internal/low volume/server side limited APIs; fix for public, high volume APIs. "Unbounded query" — OK for small known datasets, aggregations, dev/testing; fix for production queries on large tables. Security and deprecation warnings, by contrast, surface under every profile and should be treated as real. Full per case guidance, the list of what the validator no longer flags, profile strategies, the "should I fix this?" decision framework, and how to document accepted advisories are in [FALSE POSITIVES.md](FALSE POSITIVES.md) . Validation Result Structure Complete Response How to Read It 1. Check valid first — true means the config is valid; false means there are errors to fix before deployment. 2. Fix errors first — each carries a property , message , and fix . These must be resolved. 3. Review warnings — each has a message and suggestion ; decide per case whether to address it (see False Positives above). 4. Consider suggestions — optional improvements, not required. Workflow Validation validate workflow (Structure) Validates entire workflow , not just individual nodes Checks : 1. Node configurations Each node valid 2. Connections No broken references 3. Expressions Syntax and references valid 4. Flow Logical workflow structure Example : Common Workflow Errors 1. Broken Connections Fix : Remove stale connection or create missing node 2. Cycles (warning, not an error) A cycle is a warning , not a hard error (n8n mcp ≥ 2.63.0) — runtime controlled loops (error retry, data driven pagination, a router feeding back) execute to completion and are legitimate. Fix only if the loop is unintentional: ensure the cycle has a real exit (a conditional node, an error output, or a bounded counter) so it can't spin forever. 3. Multiple Start Nodes Fix : Remove extra triggers or split into separate workflows 4. Disconnected Nodes Fix : Connect node or remove if unused Recovery Strategies Strategy 1: Start Fresh When : Configuration is severely broken Steps : 1. Note required fields from get node 2. Create minimal valid configuration 3. Add features incrementally 4. Validate after each addition Strategy 2: Binary Search When : Workflow validates but executes incorrectly Steps : 1. Remove half the nodes 2. Validate and test 3. If works: problem is in removed nodes 4. If fails: problem is in remaining nodes 5. Repeat until problem isolated Strategy 3: Clean Stale Connections When : "Node not found" errors Steps : Strategy 4: Use Auto fix When : Validation errors that can be automatically resolved Steps : Auto Fix Capabilities The n8n autofix workflow tool can fix these issue types: 1. expression format Missing = prefix in expressions (e.g., {{ $json.field }} → ={{ $json.field }} ) 2. typeversion correction Downgrades nodes with unsupported typeVersions 3. error output config Removes conflicting onError settings 4. node type correction Fixes unknown node types using similarity matching (90%+ confidence) 5. webhook missing path Generates UUIDs for webhook nodes missing path configuration 6. typeversion upgrade Smart upgrades to latest node versions with auto migration 7. version migration Guidance for complex breaking changes requiring manual steps Confidence levels : high (90%+, safe to auto apply), medium (70 89%, review recommended), low (<70%, manual review required) Post update guidance : For version upgrades, check the postUpdateGuidance field in the response for step by step migration instructions. Best Practices ✅ Do Validate after every significant change Read error messages completely Fix errors iteratively (one at a time) Use runtime profile for pre deployment Check valid field before assuming success Trust auto sanitization for operator issues Use get node when unclear about requirements Document false positives you accept ❌ Don't Skip validation before activation Try to fix all errors at once Ignore error messages Use strict profile during development (too noisy) Assume validation passed (always check result) Manually fix auto sanitization issues Deploy with unresolved errors Ignore all warnings (some are important!) Running the workflow after it validates validate workflow checks structure, parameters and expressions — it never runs anything. A workflow that validates cleanly can still fail on real data, so run it once before calling it done. With a webhook, form or chat trigger: n8n test workflow({workflowId}) — the default method: "auto" detects the trigger and fires it over HTTP (the workflow must be active). Without such a t

n8n-validation-expert