n8n 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 with detail: "standard" is the most used discovery pattern
• 56 seconds average between configuration edits
• Covers 95% of use cases with 1-2K tokens response

Key insight: Most configurations need only standard detail, not full schema!

Core Concepts

1. Operation-Aware Configuration

Not all fields are always required - it depends on operation!

Example: Slack node

Key: Resource + operation determine which fields are required!

2. Property Dependencies

Fields appear/disappear based on other field values

Example: HTTP Request node

Mechanism: displayOptions control field visibility

3. Progressive Discovery

Use the right detail level:

1. get_node({detail: "standard"}) - DEFAULT

   • Quick overview (~1-2K tokens)
   • Required fields + common options
   • Use first - covers 95% of needs

2. get_node({mode: "search_properties", propertyQuery: "..."}) (for finding specific fields)

   • Find properties by name
   • Use when looking for auth, body, headers, etc.

3. get_node({detail: "full"}) (complete schema)

   • All properties (~3-8K tokens)
   • Use only when standard detail is insufficient

Configuration Workflow

Standard Process

Example: Configuring HTTP Request

Step 1: Identify what you need

Step 2: Get node info

Step 3: Minimal config

Step 4: Validate

Step 5: Add required field

Step 6: Validate again

Step 7: Complete configuration

Step 8: Final validation

get_node Detail Levels

Standard Detail (DEFAULT - Use This!)

✅ Starting configuration

Returns (~1-2K tokens):

• Required fields
• Common options
• Operation list
• Metadata

Use: 95% of configuration needs

Full Detail (Use Sparingly)

✅ When standard isn't enough

Returns (~3-8K tokens):

• Complete schema
• All properties
• All nested options

Warning: Large response, use only when standard insufficient

Search Properties Mode

✅ Looking for specific field

Use: Find authentication, headers, body fields, etc.

Decision Tree

Property Dependencies Deep Dive

displayOptions Mechanism

Fields have visibility rules:

Translation: "body" field shows when:

• sendBody = true AND
• method = POST, PUT, or PATCH

Common Dependency Patterns

Pattern 1: Boolean Toggle

Example: HTTP Request sendBody

Pattern 2: Operation Switch

Example: Slack resource/operation

Pattern 3: Type Selection

Example: IF node conditions

Finding Property Dependencies

Use get_node with search_properties mode:

Or use full detail for complete schema:

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:

How to configure:

1. Choose resource
2. Choose operation
3. Use get_node to see operation-specific requirements
4. Configure required fields

Pattern 2: HTTP-Based Nodes

Examples: HTTP Request, Webhook

Structure:

Dependencies:

• POST/PUT/PATCH → sendBody available
• sendBody=true → body required
• authentication != "none" → credentials required

Pattern 3: Database Nodes

Examples: Postgres, MySQL, MongoDB

Structure:

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:

Dependencies:

• Binary operators (equals, contains, etc.) → value1 + value2
• Unary operators (isEmpty, isNotEmpty) → value1 only + singleValue: true

Operation-Specific Configuration

Slack Node Examples

Post Message

Update Message

Create Channel

HTTP Request Node Examples

GET Request

POST with JSON

IF Node Examples

String Comparison (Binary)

Empty Check (Unary)

Handling Conditional Requirements

Example: HTTP Request Body

Scenario: body field required, but only sometimes

Rule:

How to discover:

Example: IF Node singleValue

Scenario: singleValue property appears for unary operators

Rule:

Good news: Auto-sanitization fixes this!

Manual check:

Configuration Anti-Patterns

❌ Don't: Over-configure Upfront

Bad:

Good:

❌ Don't: Skip Validation

Bad:

Good:

❌ Don't: Ignore Operation Context

Bad:

Good:

Best Practices

✅ Do

1. Start with get_node (standard detail)

   • ~1-2K tokens response
   • Covers 95% of configuration needs
   • Default detail level

2. Validate iteratively

   • Configure → Validate → Fix → Repeat
   • Average 2-3 iterations is normal
   • Read validation errors carefully

3. Use search_properties mode when stuck

   • If field seems missing, search for it
   • Understand what controls field visibility
   • get_node({mode: "search_properties", propertyQuery: "..."})

4. Respect operation context

   • Different operations = different requirements
   • Always check get_node when changing operation
   • Don't assume configs are transferable

5. Trust auto-sanitization

   • Operator structure fixed automatically
   • Don't manually add/remove singleValue
   • IF/Switch metadata added on save

❌ Don't

1. Jump to detail="full" immediately

   • Try standard detail first
   • Only escalate if needed
   • Full schema is 3-8K tokens

2. Configure blindly

   • Always validate before deploying
   • Understand why fields are required
   • Use search_properties for conditional fields

3. Copy configs without understanding

   • Different operations need different fields
   • Validate after copying
   • Adjust for new context

4. 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:

1. Start with get_node (standard detail is default)
2. Configure required fields for operation
3. Validate configuration
4. Search properties if stuck
5. Iterate until valid (avg 2-3 cycles)
6. 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