タグ
説明
- name:n8n-node-configuration
- description: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.
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_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
関連スキル
これらにも興味があるかもしれません
Command Development
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
iterate-pr
Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.
n8n-code-javascript
Write JavaScript code in n8n Code nodes. Use when writing JavaScript in n8n, using $input/$json/$node syntax, making HTTP requests with $helpers, working with dates using DateTime, troubleshooting Code node errors, or choosing between Code node modes.