Claude-code-templates n8n-node-configuration
Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node_essentials and get_node_info, or learning common configuration patterns by node type.
git clone https://github.com/davila7/claude-code-templates
T=$(mktemp -d) && git clone --depth=1 https://github.com/davila7/claude-code-templates "$T" && mkdir -p ~/.claude/skills && cp -r "$T/cli-tool/components/skills/workflow-automation/n8n/n8n-node-configuration" ~/.claude/skills/davila7-claude-code-templates-n8n-node-configuration && rm -rf "$T"
cli-tool/components/skills/workflow-automation/n8n/n8n-node-configuration/SKILL.mdn8n Node Configuration
Expert guidance for operation-aware node configuration with property dependencies.
Configuration Philosophy
Progressive disclosure: Start minimal, add complexity as needed
Configuration best practices:
- get_node_essentials is the most used discovery pattern
- 56 seconds average between configuration edits
- 91.7% success rate with essentials-based configuration
Key insight: Most configurations need only essentials, not full schema!
Core Concepts
1. Operation-Aware Configuration
Not all fields are always required - it depends on operation!
Example: Slack node
// For operation='post' { "resource": "message", "operation": "post", "channel": "#general", // Required for post "text": "Hello!" // Required for post } // For operation='update' { "resource": "message", "operation": "update", "messageId": "123", // Required for update (different!) "text": "Updated!" // Required for update // channel NOT required for update }
Key: Resource + operation determine which fields are required!
2. Property Dependencies
Fields appear/disappear based on other field values
Example: HTTP Request node
// When method='GET' { "method": "GET", "url": "https://api.example.com" // sendBody not shown (GET doesn't have body) } // When method='POST' { "method": "POST", "url": "https://api.example.com", "sendBody": true, // Now visible! "body": { // Required when sendBody=true "contentType": "json", "content": {...} } }
Mechanism: displayOptions control field visibility
3. Progressive Discovery
Use the right tool for the right job:
-
get_node_essentials (91.7% success rate)
- Quick overview
- Required fields
- Common options
- Use first - covers 90% of needs
-
get_property_dependencies (for complex nodes)
- Shows what fields depend on others
- Reveals conditional requirements
- Use when essentials isn't enough
-
get_node_info (full schema)
- Complete documentation
- All possible fields
- Use when essentials + dependencies insufficient
Configuration Workflow
Standard Process
1. Identify node type and operation ↓ 2. Use get_node_essentials ↓ 3. Configure required fields ↓ 4. Validate configuration ↓ 5. If dependencies unclear → get_property_dependencies ↓ 6. Add optional fields as needed ↓ 7. Validate again ↓ 8. Deploy
Example: Configuring HTTP Request
Step 1: Identify what you need
// Goal: POST JSON to API
Step 2: Get essentials
const info = get_node_essentials({ nodeType: "nodes-base.httpRequest" }); // Returns: method, url, sendBody, body, authentication required/optional
Step 3: Minimal config
{ "method": "POST", "url": "https://api.example.com/create", "authentication": "none" }
Step 4: Validate
validate_node_operation({ nodeType: "nodes-base.httpRequest", config, profile: "runtime" }); // → Error: "sendBody required for POST"
Step 5: Add required field
{ "method": "POST", "url": "https://api.example.com/create", "authentication": "none", "sendBody": true }
Step 6: Validate again
validate_node_operation({...}); // → Error: "body required when sendBody=true"
Step 7: Complete configuration
{ "method": "POST", "url": "https://api.example.com/create", "authentication": "none", "sendBody": true, "body": { "contentType": "json", "content": { "name": "={{$json.name}}", "email": "={{$json.email}}" } } }
Step 8: Final validation
validate_node_operation({...}); // → Valid! ✅
get_node_essentials vs get_node_info
Use get_node_essentials When:
✅ Starting configuration (91.7% success rate)
get_node_essentials({ nodeType: "nodes-base.slack" });
Returns:
- Required fields
- Common options
- Basic examples
- Operation list
Fast: ~18 seconds average (from search → essentials)
Use get_node_info When:
✅ Essentials insufficient
get_node_info({ nodeType: "nodes-base.slack" });
Returns:
- Full schema
- All properties
- Complete documentation
- Advanced options
Slower: More data to process
Decision Tree
┌─────────────────────────────────┐ │ Starting new node config? │ ├─────────────────────────────────┤ │ YES → get_node_essentials │ └─────────────────────────────────┘ ↓ ┌─────────────────────────────────┐ │ Essentials has what you need? │ ├─────────────────────────────────┤ │ YES → Configure with essentials │ │ NO → Continue │ └─────────────────────────────────┘ ↓ ┌─────────────────────────────────┐ │ Need dependency info? │ ├─────────────────────────────────┤ │ YES → get_property_dependencies │ │ NO → Continue │ └─────────────────────────────────┘ ↓ ┌─────────────────────────────────┐ │ Still need more details? │ ├─────────────────────────────────┤ │ YES → get_node_info │ └─────────────────────────────────┘
Property Dependencies Deep Dive
displayOptions Mechanism
Fields have visibility rules:
{ "name": "body", "displayOptions": { "show": { "sendBody": [true], "method": ["POST", "PUT", "PATCH"] } } }
Translation: "body" field shows when:
- sendBody = true AND
- method = POST, PUT, or PATCH
Common Dependency Patterns
Pattern 1: Boolean Toggle
Example: HTTP Request sendBody
// sendBody controls body visibility { "sendBody": true // → body field appears }
Pattern 2: Operation Switch
Example: Slack resource/operation
// Different operations → different fields { "resource": "message", "operation": "post" // → Shows: channel, text, attachments, etc. } { "resource": "message", "operation": "update" // → Shows: messageId, text (different fields!) }
Pattern 3: Type Selection
Example: IF node conditions
{ "type": "string", "operation": "contains" // → Shows: value1, value2 } { "type": "boolean", "operation": "equals" // → Shows: value1, value2, different operators }
Using get_property_dependencies
Example:
const deps = get_property_dependencies({ nodeType: "nodes-base.httpRequest" }); // Returns dependency tree { "dependencies": { "body": { "shows_when": { "sendBody": [true], "method": ["POST", "PUT", "PATCH", "DELETE"] } }, "queryParameters": { "shows_when": { "sendQuery": [true] } } } }
Use this when: Validation fails and you don't understand why field is missing/required
Common Node Patterns
Pattern 1: Resource/Operation Nodes
Examples: Slack, Google Sheets, Airtable
Structure:
{ "resource": "<entity>", // What type of thing "operation": "<action>", // What to do with it // ... operation-specific fields }
How to configure:
- Choose resource
- Choose operation
- Use get_node_essentials to see operation-specific requirements
- Configure required fields
Pattern 2: HTTP-Based Nodes
Examples: HTTP Request, Webhook
Structure:
{ "method": "<HTTP_METHOD>", "url": "<endpoint>", "authentication": "<type>", // ... method-specific fields }
Dependencies:
- POST/PUT/PATCH → sendBody available
- sendBody=true → body required
- authentication != "none" → credentials required
Pattern 3: Database Nodes
Examples: Postgres, MySQL, MongoDB
Structure:
{ "operation": "<query|insert|update|delete>", // ... operation-specific fields }
Dependencies:
- operation="executeQuery" → query required
- operation="insert" → table + values required
- operation="update" → table + values + where required
Pattern 4: Conditional Logic Nodes
Examples: IF, Switch, Merge
Structure:
{ "conditions": { "<type>": [ { "operation": "<operator>", "value1": "...", "value2": "..." // Only for binary operators } ] } }
Dependencies:
- Binary operators (equals, contains, etc.) → value1 + value2
- Unary operators (isEmpty, isNotEmpty) → value1 only + singleValue: true
Operation-Specific Configuration
Slack Node Examples
Post Message
{ "resource": "message", "operation": "post", "channel": "#general", // Required "text": "Hello!", // Required "attachments": [], // Optional "blocks": [] // Optional }
Update Message
{ "resource": "message", "operation": "update", "messageId": "1234567890", // Required (different from post!) "text": "Updated!", // Required "channel": "#general" // Optional (can be inferred) }
Create Channel
{ "resource": "channel", "operation": "create", "name": "new-channel", // Required "isPrivate": false // Optional // Note: text NOT required for this operation }
HTTP Request Node Examples
GET Request
{ "method": "GET", "url": "https://api.example.com/users", "authentication": "predefinedCredentialType", "nodeCredentialType": "httpHeaderAuth", "sendQuery": true, // Optional "queryParameters": { // Shows when sendQuery=true "parameters": [ { "name": "limit", "value": "100" } ] } }
POST with JSON
{ "method": "POST", "url": "https://api.example.com/users", "authentication": "none", "sendBody": true, // Required for POST "body": { // Required when sendBody=true "contentType": "json", "content": { "name": "John Doe", "email": "john@example.com" } } }
IF Node Examples
String Comparison (Binary)
{ "conditions": { "string": [ { "value1": "={{$json.status}}", "operation": "equals", "value2": "active" // Binary: needs value2 } ] } }
Empty Check (Unary)
{ "conditions": { "string": [ { "value1": "={{$json.email}}", "operation": "isEmpty", // No value2 - unary operator "singleValue": true // Auto-added by sanitization } ] } }
Handling Conditional Requirements
Example: HTTP Request Body
Scenario: body field required, but only sometimes
Rule:
body is required when: - sendBody = true AND - method IN (POST, PUT, PATCH, DELETE)
How to discover:
// Option 1: Read validation error validate_node_operation({...}); // Error: "body required when sendBody=true" // Option 2: Check dependencies get_property_dependencies({ nodeType: "nodes-base.httpRequest" }); // Shows: body → shows_when: sendBody=[true], method=[POST,PUT,PATCH,DELETE] // Option 3: Try minimal config and iterate // Start without body, validation will tell you if needed
Example: IF Node singleValue
Scenario: singleValue property appears for unary operators
Rule:
singleValue should be true when: - operation IN (isEmpty, isNotEmpty, true, false)
Good news: Auto-sanitization fixes this!
Manual check:
get_property_dependencies({ nodeType: "nodes-base.if" }); // Shows operator-specific dependencies
Configuration Anti-Patterns
❌ Don't: Over-configure Upfront
Bad:
// Adding every possible field { "method": "GET", "url": "...", "sendQuery": false, "sendHeaders": false, "sendBody": false, "timeout": 10000, "ignoreResponseCode": false, // ... 20 more optional fields }
Good:
// Start minimal { "method": "GET", "url": "...", "authentication": "none" } // Add fields only when needed
❌ Don't: Skip Validation
Bad:
// Configure and deploy without validating const config = {...}; n8n_update_partial_workflow({...}); // YOLO
Good:
// Validate before deploying const config = {...}; const result = validate_node_operation({...}); if (result.valid) { n8n_update_partial_workflow({...}); }
❌ Don't: Ignore Operation Context
Bad:
// Same config for all Slack operations { "resource": "message", "operation": "post", "channel": "#general", "text": "..." } // Then switching operation without updating config { "resource": "message", "operation": "update", // Changed "channel": "#general", // Wrong field for update! "text": "..." }
Good:
// Check requirements when changing operation get_node_essentials({ nodeType: "nodes-base.slack" }); // See what update operation needs (messageId, not channel)
Best Practices
✅ Do
-
Start with get_node_essentials
- 91.7% success rate
- Faster than get_node_info
- Sufficient for most needs
-
Validate iteratively
- Configure → Validate → Fix → Repeat
- Average 2-3 iterations is normal
- Read validation errors carefully
-
Use property dependencies when stuck
- If field seems missing, check dependencies
- Understand what controls field visibility
- get_property_dependencies reveals rules
-
Respect operation context
- Different operations = different requirements
- Always check essentials when changing operation
- Don't assume configs are transferable
-
Trust auto-sanitization
- Operator structure fixed automatically
- Don't manually add/remove singleValue
- IF/Switch metadata added on save
❌ Don't
-
Jump to get_node_info immediately
- Try essentials first
- Only escalate if needed
- Full schema is overwhelming
-
Configure blindly
- Always validate before deploying
- Understand why fields are required
- Check dependencies for conditional fields
-
Copy configs without understanding
- Different operations need different fields
- Validate after copying
- Adjust for new context
-
Manually fix auto-sanitization issues
- Let auto-sanitization handle operator structure
- Focus on business logic
- Save and let system fix structure
Detailed References
For comprehensive guides on specific topics:
- DEPENDENCIES.md - Deep dive into property dependencies and displayOptions
- OPERATION_PATTERNS.md - Common configuration patterns by node type
Summary
Configuration Strategy:
- Start with get_node_essentials (91.7% success)
- Configure required fields for operation
- Validate configuration
- Check dependencies if stuck
- Iterate until valid (avg 2-3 cycles)
- Deploy with confidence
Key Principles:
- Operation-aware: Different operations = different requirements
- Progressive disclosure: Start minimal, add as needed
- Dependency-aware: Understand field visibility rules
- Validation-driven: Let validation guide configuration
Related Skills:
- n8n MCP Tools Expert - How to use discovery tools correctly
- n8n Validation Expert - Interpret validation errors
- n8n Expression Syntax - Configure expression fields
- n8n Workflow Patterns - Apply patterns with proper configuration