I Broke n8n (So You Don't Have To)

The Error That Wouldn't Go Away

I'm building AI-powered automation systems with n8n and Claude Code. The workflow: design the logic, have Claude generate the n8n workflow JSON, import it into my Railway-hosted n8n instance, and deploy. Simple, right?

Except every single workflow Claude generated failed on import with the same cryptic error:

The canvas would go blank. No nodes. Just "Add first step..." mocking me. The workflow JSON looked perfectly valid — proper structure, correct node types, reasonable parameters. But n8n rejected it every time.

This wasn't a one-off glitch. It happened consistently across multiple workflows, multiple browsers, and multiple attempts. I spent hours chasing ghosts before finding the real culprit.

What I Tried First (All Wrong)

None of these were the issue. The problem was in the JSON itself — specifically, in the parameter schemas that Claude Code was generating.

The Real Problem: Schema Mismatch

n8n's internal node parameter schemas are strict and version-specific. They're not publicly documented in a way that AI models can learn from. So when Claude (or any AI) generates n8n workflow JSON, it produces something that looks correct but doesn't match what n8n actually validates against.

This is a widely reported problem in the n8n community. The error message "Could not find property option" is n8n's way of saying: "I found a parameter structure I don't recognize for this node type and version."

Even small deviations — a wrong property name, an outdated typeVersion, or a misplaced field — cause silent failures where the workflow appears blank with an "Add first step..." prompt.

Isolating the Culprit: Node by Node

I stripped the workflow down to the bare minimum and added nodes back one at a time:

The Switch node was the culprit. Its parameter schema changed between n8n versions, and Claude was generating the old format.

The Diff: What Claude Generated vs. What n8n Expects

I manually created a Switch node in the n8n UI, exported the workflow, and compared the JSON side by side. The differences were small but fatal:

Five differences. That's it. Five small schema mismatches that made the entire workflow unimportable. The biggest one — rules.rules vs rules.values — is just a property name change between n8n versions. But it's enough to trigger "Could not find property option."

The Correct Switch Node Schema (n8n v2.11.3)

For anyone hitting this error, here's the exact Switch node structure that n8n v2.11.3 accepts:

{
  "parameters": {
    "rules": {
      "values": [              // NOT "rules"
        {
          "conditions": {
            "options": {
              "caseSensitive": true,   // NOT false
              "leftValue": "",
              "typeValidation": "strict",
              "version": 3             // NOT 2
            },
            "conditions": [
              {
                "leftValue": "={{ $json.myField }}",
                "rightValue": "someValue",
                "operator": {
                  "type": "string",
                  "operation": "equals"
                },
                "id": "uuid-here"      // ID goes HERE
              }
            ],
            "combinator": "and"
          }
        }
      ]
    },
    "options": {}
  },
  "type": "n8n-nodes-base.switch",
  "typeVersion": 3.4               // NOT 3 or 3.2
}

Other Nodes That Break (And Their Fixes)

// Instead of a Set node, use a Code node:
{
  "parameters": {
    "jsCode": "const input = $input.first().json;\nreturn [{\n  json: {\n    myField: input.something || ''\n  }\n}];"
  },
  "type": "n8n-nodes-base.code",
  "typeVersion": 2
}

"workflowId": {
  "__rl": true,
  "value": "abc123",
  "mode": "id"
}

"workflowId": "abc123"

Node TypeVersions Cheat Sheet (n8n v2.11.3)

Required Top-Level Workflow Structure

Beyond individual nodes, the workflow JSON itself needs specific top-level fields. Missing any of these can cause import failures or unexpected behavior:

{
  "name": "Workflow Name",
  "nodes": [],
  "pinData": {},                    // Required, even if empty
  "connections": {},
  "active": false,
  "settings": {
    "executionOrder": "v1",
    "binaryMode": "separate",       // Often missed
    "availableInMCP": false          // Often missed
  },
  "tags": []
}

// Do NOT include: versionId, meta, or id
// — n8n generates these on import

Other Gotchas

The Debugging Playbook

If you hit "Could not find property option" or any import failure, here's the process that actually works:

1. Start minimal — create a workflow with just Webhook + Respond to Webhook (known-good baseline)
2. Add one node at a time — import after each addition to isolate which node breaks it
3. Export from the n8n UI — if you're unsure about a node's schema, add it manually in the n8n editor, export the workflow, and copy the exact parameter structure
4. Check typeVersion first — most failures come from using outdated typeVersions
5. Check the Switch node — it's the #1 failure point. Verify rules.values (not rules.rules), typeVersion 3.4, and conditions version 3
6. Never guess Set node schemas — use Code nodes instead, every time

The Permanent Fix: A Generation Guide

After documenting every schema difference, I built an n8n Workflow Generation Guide and baked it directly into my project's CLAUDE.md file — the instruction file that Claude Code reads before doing any work.

The guide contains the exact typeVersions, correct parameter schemas for every common node, a complete working example workflow, and a debugging checklist. Now when I ask Claude Code to generate an n8n workflow, it follows these rules and produces importable JSON on the first try.

The key insight: AI coding tools are powerful, but they hallucinate schemas. When you're working with strict validation systems like n8n, you need to export from the real system, compare against what the AI generates, codify the correct patterns, and feed them back into the AI's context. Don't fight the AI — teach it.

The Takeaway

This debugging session cost me hours, but the generation guide saves me hours on every workflow I build going forward. The pattern is universal:

• 1.When AI-generated output fails validation in a strict system, don't blame the AI — the system's schema is underdocumented
• 2.Export a working example from the real system and diff it against the AI's output
• 3.Document every deviation and feed it back into the AI's instructions
• 4.The AI gets it right every time after that — the upfront cost pays for itself immediately

Building in public means sharing the ugly debugging sessions too. Not every post is a success story — sometimes the most valuable thing you can share is the hours you spent staring at a wrong property name.