AutoGineer
Generated banner for N8n Node Configuration
Generated logo for N8n Node Configuration

N8n Node Configuration

Romuald CzlonkowskiCommunityCreated by Romuald Czlonkowski

  • Skill
  • Tool integration
  • Automation and integrations
  • MIT
  • No issues found
Download ZIP

From the author

Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node detail levels, or learning common configuration patterns by node type — including the native nodes that replace Code (Summarize, Aggregate, Split Out, Merge, Compare Datasets, Remove Duplicates, Sort, Limit, Date & Time, HTTP Request pagination, Crypto). Always use this skill when setting up node parameters — it explains which fields are required for each operation, how displayOptions control field visibility, and when to use patchNodeField for surgical edits vs full node updates.
— the description by Romuald Czlonkowski

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to configuring n8n nodes, emphasizing an operation-aware methodology. It teaches users how to navigate property dependencies, manage field visibility via displayOptions, and utilize iterative validation to ensure correct node setup. By following a progressive disclosure model—starting with standard detail levels before escalating to full schemas—users can efficiently configure complex nodes, including native replacements for Code nodes, while avoiding common pitfalls and silent runtime failures.

What it does

  • Explains how to determine required fields based on specific node operations.
  • Guides users on using get_node detail levels to balance information density and clarity.
  • Provides strategies for handling conditional field visibility and property dependencies.
  • Outlines best practices for configuring HTTP, database, and conditional logic nodes.
  • Demonstrates how to perform surgical field updates using patchNodeField.
  • Identifies common configuration anti-patterns and silent failure traps.

When to use it

  • When setting up parameters for any n8n node to ensure accuracy.
  • When encountering validation errors regarding missing or conflicting fields.
  • When transitioning between different operations within the same node.
  • When needing to configure complex native nodes like Merge, Summarize, or HTTP Request.
  • When troubleshooting silent failures in workflow execution.

Advantages

  • Reduces configuration errors through iterative, validation-driven workflows.
  • Prevents over-configuration by promoting a minimal-first approach.
  • Clarifies complex dependency logic between fields.
  • Provides actionable patterns for native data processing nodes.
  • Minimizes token usage by prioritizing standard detail levels.

Usage examples

“How do I configure the Slack node to post a message?”
The agent will guide you to use get_node to identify the required 'channel' and 'text' fields for the 'post' operation, ensuring you avoid unnecessary parameters.
“Why is my HTTP Request node failing when I switch to POST?”
The agent will explain that the 'sendBody' and 'body' fields are now required, and help you configure them using the appropriate dependency patterns.
“How can I update just the URL in a large HTTP Request node?”
The agent will provide the syntax for using patchNodeField to surgically update the URL parameter without replacing the entire node configuration.
“What is the best way to find a specific authentication field in a node?”
The agent will instruct you to use get_node with the 'search_properties' mode and 'auth' as the propertyQuery to locate the exact field.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/czlonkowski/n8n-node-configuration/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip n8n-node-configuration.zip -d .agents/skills

Documentation by Romuald Czlonkowski

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

// 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 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

  1. Identify node type and operation.

  2. Use get_node (standard detail is default).

  3. Configure required fields.

  4. Validate configuration.

  5. If a field is unclear → get_node({mode: "search_properties"}).

  6. Add optional fields as needed.

  7. Validate again.

  8. Deploy.

Example: Configuring HTTP Request

The validate-driven loop in practice: start minimal (method, url, authentication), then let each validate_node error surface the next required field (sendBody for POST → body when sendBody=true) until valid. Full step-by-step walkthrough in OPERATION_PATTERNS.md.

get_node Detail Levels

Standard Detail (DEFAULT - Use This!)

✅ Starting configuration

get_node({
  nodeType: "nodes-base.slack"
});
// detail="standard" is the default

Returns (~1-2K tokens):

  • Required fields, resolved for the node's current typeVersion

  • Operation list

  • The settings inside options collections (n8n-mcp 2.97.0+): name + one line with nested field names, allowed values and when each applies — HTTP Request pagination and batching, Webhook raw body, Merge combine settings, …

  • Metadata

Use: 95% of configuration needs. Read the options list before deciding a job needs a Code node.

Full Detail (Use Sparingly)

✅ When standard isn't enough

get_node({
  nodeType: "nodes-base.slack",
  detail: "full"
});

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

get_node({
  nodeType: "nodes-base.httpRequest",
  mode: "search_properties",
  propertyQuery: "auth"
});

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

Decision Tree

  1. Starting a new node config → get_node (standard).

  2. Standard has what you need → configure with it. Otherwise continue. (On n8n-mcp 2.97.0+ standard also lists each options collection; a list cut at 25 settings says so.)

  3. Looking for a specific field → search_properties mode. Otherwise continue.

  4. Still need more → get_node({detail: "full"}).

Dynamic properties: when standard detail marks a property with dynamicOptions: {methodName, methodType, dependsOn}, its real values come from a live loadOptions/listSearch method, not from bundled docs — don't guess an ID for it. Resolve it with n8n_explore_node_resources (needs N8N_MCP_ACCESS_TOKEN, n8n 2.34+) and put the returned value in the config; name is display text only.

All six parameters are required and none are inferred from each other:

n8n_explore_node_resources({
  nodeType: "n8n-nodes-base.googleSheets",  // LONG form
  version: 4.5,                              // the node typeVersion the method belongs to
  methodName: "getSheets",                   // copied verbatim from dynamicOptions
  methodType: "listSearch",                  // "listSearch" for resource locators, "loadOptions" for plain dropdowns
  credentialType: "googleSheetsOAuth2Api",
  credentialId: "c2",                        // from n8n_manage_credentials({action: "list"})
  currentNodeParameters: {                   // whatever dependsOn names, in its real shape
    documentId: {__rl: true, mode: "id", value: "1AbC…"}
  }
})

dependsOn names the parameters the method needs already chosen — pass them in currentNodeParameters, keeping resource-locator values in their {__rl: true, mode, value} shape, or the method returns nothing useful. methodName is case-sensitive and specific to the nodeType + version pair; a mismatch returns OFFICIAL_MCP_ERROR rather than an empty list.

Property Dependencies Deep Dive

Fields have displayOptions visibility rules: show/hide blocks where multiple conditions are AND'd and multiple values are OR'd (e.g. body shows when sendBody=true AND method IN (POST, PUT, PATCH)). The three recurring patterns are the boolean toggle (sendBody → body), the operation switch (post vs update show different fields), and type selection (string vs boolean conditions). To find what controls a field, use get_node({mode: "search_properties", propertyQuery: "..."}) or get_node({detail: "full"}) — especially when validation flags a field you don't see.

Mechanism details, all four dependency patterns, complex flows, nested dependencies, and troubleshooting are in DEPENDENCIES.md (quick-reference recap under Quick Reference: displayOptions and Common Dependency Patterns).

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:

  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:

{
  "method": "<HTTP_METHOD>",
  "url": "<endpoint>",
  "authentication": "<type>",
  // ... method-specific fields
}

Dependencies:

  • POST/PUT/PATCH → sendBody available

  • sendBody=true → body required

  • authentication != "none" → credentials required

Critical: credentials block, node id, typeVersion

  • Never set a placeholder credential ID (e.g. "id": "REPLACE_ME") — n8n's UI renders a permanently disabled credential selector for unknown IDs. Omit the credentials block when the real ID is unknown; the user then gets a normal clickable dropdown.

  • Node id must be a UUID v4, not a readable slug — the frontend binds forms and the credential component to it.

  • Don't hardcode old typeVersion values — verify the current version with get_node (httpRequest is 4.4+).

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

Critical: Write operations may return 0 items

  • INSERT, UPDATE, DELETE can produce 0 n8n output items, depending on the node and operation (raw query execution reliably returns 0 result rows; some database nodes return the affected rows)

  • Set alwaysOutputData: true on write-operation nodes to keep downstream chains alive

  • Downstream nodes should use $('UpstreamNode').all() instead of $input if they need data

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

Required fields shift with resource + operation: Slack post needs channel+text, but update needs messageId+text (channel optional) and channel/create needs name. HTTP GET uses sendQuery+queryParameters; POST needs sendBody+body. IF binary operators (equals) need value1+value2; unary (isEmpty) need only value1 plus auto-added singleValue: true. Concrete minimal configs for each in OPERATION_PATTERNS.md.

Handling Conditional Requirements

Some fields are required only under certain conditions: HTTP body is required when sendBody=true AND method IN (POST, PUT, PATCH, DELETE); IF singleValue should be true when the operator is unary (isEmpty, isNotEmpty, true, false) — and auto-sanitization sets it for you. Discover conditional requirements by reading the validation error, searching the property (get_node({mode: "search_properties"})), or iterating from a minimal config. Worked discovery examples in DEPENDENCIES.md.

Node-Specific Configuration Notes

SplitInBatches v3
{
  "batchSize": 100,  // Number of items per batch
  "options": {}
}

Output wiring:

  • main[0] (done) → Connect to downstream processing (add Limit 1 first)

  • main[1] (each batch) → Connect to loop body, then loop back to SplitInBatches input

See the n8n Workflow Patterns skill for detailed loop and nested loop patterns.

Google Sheets Node

Per-item execution: Each input item triggers a separate API call. If you have 100 items and use a Google Sheets "Append Row" node, it makes 100 API calls. To write in bulk, collect the rows into one item with an Aggregate node first, then use a single HTTP Request with the Sheets API.

Formula columns: Never use append on sheets with formula columns — it overwrites formulas. Instead, use HTTP Request with Google Sheets API values.update (PUT) method and a googleApi credential.

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({...});
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({
  nodeType: "nodes-base.slack"
});
// See what update operation needs (messageId, not channel)

Surgical Field Edits with patchNodeField

When you need to edit a specific string inside a node field — rather than replacing the whole field — use patchNodeField in n8n_update_partial_workflow. This is especially useful for:

  • Editing code inside Code nodes without re-transmitting the full code block

  • Updating URLs or text in large HTML email templates

  • Fixing typos in JSON bodies or long text fields

// Instead of replacing the entire jsCode field:
n8n_update_partial_workflow({
  id: "wf-123",
  operations: [{
    type: "patchNodeField",
    nodeName: "Code",
    fieldPath: "parameters.jsCode",
    patches: [{find: "const limit = 10;", replace: "const limit = 50;"}]
  }]
})

patchNodeField is strict — it errors if the find string isn't found or matches multiple times (unless replaceAll: true). This prevents accidental silent failures during configuration updates. See the n8n MCP Tools Expert skill for full syntax and examples.

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

Native Nodes for Data Jobs

The job-to-node table in using-n8n-mcp-skills picks the node; NATIVE_NODES.md has each one's parameters JSON and traps. The traps that bite most:

  • Summarize — fieldsToSplitBy is one comma-separated string; outputs are named sum_amount, count_id, …

  • Split Out — include defaults to noOtherFields: the parent's fields are dropped unless you keep them.

  • Merge — combineByFields + joinMode (keepMatches, keepNonMatches, enrichInput1, …); numberInputs only on append / SQL / position / choose-branch modes.

  • Compare Datasets — four outputs in fixed order: in A only, same, different, in B only.

  • Remove Duplicates — removeItemsSeenInPreviousExecutions dedupes across runs (v2), replacing static-data Code.

  • Date & Time — set options.includeInputFields: true, or only the new date field survives.

  • HTTP Request pagination — always limitPagesFetched: true + maxRequests; an object body arrives as one item per page.

  • Crypto — use typeVersion 2: HMAC and signing secrets come from a crypto credential (v1 kept them in the JSON).

  • Node settings — executeOnce, alwaysOutputData, notes / notesInFlow sit next to parameters, not inside it.

Silent-Failure Gotchas by Node Family

Some misconfigurations pass validate_node and validate_workflow clean, run without error, and quietly do the wrong thing — get_node shows the fields exist but not what happens when you omit them. The high-frequency ones:

  • Switch — no options.fallbackOutput ⇒ unmatched items silently dropped.

  • Merge — numberInputs defaults to 2 (extra sources drop; numberOfInputs is not a field and is ignored); useDataOfInput is 1-indexed vs the 0-indexed connections.<src>.main[idx] slot (useDataOfInput: "N" → main[N-1]).

  • Database — {{ }} interpolation into parameters.query is SQL injection; use $1/$2 placeholders + options.queryReplacement.

  • Slack — Block Kit must be wrapped ={{ { "blocks": ... } }} or it posts as plain text.

  • Webhook / Respond — options.responseCode defaults to 200 even on error branches; a top-level responseCode is ignored.

  • Schedule Trigger — timezone is workflow-level (Workflow Settings), not per-rule.

Full symptom/cause/fix detail (in JSON + n8n_update_partial_workflow terms) in NODE_FAMILY_GOTCHAS.md.

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

  • NATIVE_NODES.md - Configs for the native nodes that replace Code (transform, dedupe, diff, dates, pagination, HMAC, files) and node settings

  • NODE_FAMILY_GOTCHAS.md - Silent runtime traps by family (Switch, Merge, Database, Slack, Webhook, Schedule)

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

Files

OPERATION_PATTERNS.md

Operation Patterns Guide

Common node configuration patterns organized by node type and operation.

Overview

Purpose: Quick reference for common node configurations

Coverage: Top 20 most-used nodes from 525 available

Pattern format:

  • Minimal valid configuration

  • Common options

  • Real-world examples

  • Gotchas and tips

HTTP & API Nodes

HTTP Request (nodes-base.httpRequest)

Most versatile node for HTTP operations

GET Request

Minimal:

{
  "method": "GET",
  "url": "https://api.example.com/users",
  "authentication": "none"
}

With query parameters:

{
  "method": "GET",
  "url": "https://api.example.com/users",
  "authentication": "none",
  "sendQuery": true,
  "queryParameters": {
    "parameters": [
      {
        "name": "limit",
        "value": "100"
      },
      {
        "name": "offset",
        "value": "={{$json.offset}}"
      }
    ]
  }
}

With authentication:

{
  "method": "GET",
  "url": "https://api.example.com/users",
  "authentication": "predefinedCredentialType",
  "nodeCredentialType": "httpHeaderAuth"
}
POST with JSON

Minimal:

{
  "method": "POST",
  "url": "https://api.example.com/users",
  "authentication": "none",
  "sendBody": true,
  "body": {
    "contentType": "json",
    "content": {
      "name": "John Doe",
      "email": "[email protected]"
    }
  }
}

With expressions:

{
  "method": "POST",
  "url": "https://api.example.com/users",
  "authentication": "none",
  "sendBody": true,
  "body": {
    "contentType": "json",
    "content": {
      "name": "={{$json.name}}",
      "email": "={{$json.email}}",
      "metadata": {
        "source": "n8n",
        "timestamp": "={{$now.toISO()}}"
      }
    }
  }
}

Gotcha: Remember sendBody: true for POST/PUT/PATCH!

PUT/PATCH Request

Pattern: Same as POST, but method changes

{
  "method": "PUT",  // or "PATCH"
  "url": "https://api.example.com/users/123",
  "authentication": "none",
  "sendBody": true,
  "body": {
    "contentType": "json",
    "content": {
      "name": "Updated Name"
    }
  }
}
DELETE Request

Minimal (no body):

{
  "method": "DELETE",
  "url": "https://api.example.com/users/123",
  "authentication": "none"
}

With body (some APIs allow):

{
  "method": "DELETE",
  "url": "https://api.example.com/users",
  "authentication": "none",
  "sendBody": true,
  "body": {
    "contentType": "json",
    "content": {
      "ids": ["123", "456"]
    }
  }
}
Webhook (nodes-base.webhook)

Most common trigger - 813 searches!

Basic Webhook

Minimal:

{
  "path": "my-webhook",
  "httpMethod": "POST",
  "responseMode": "onReceived"
}

Gotcha: Webhook data is under $json.body, not $json!

// ❌ Wrong
{
  "text": "={{$json.email}}"
}

// ✅ Correct
{
  "text": "={{$json.body.email}}"
}
Webhook with Authentication

Header auth:

{
  "path": "secure-webhook",
  "httpMethod": "POST",
  "responseMode": "onReceived",
  "authentication": "headerAuth",
  "options": {
    "responseCode": { "values": { "responseCode": 200 } },
    "responseData": "{\n  \"success\": true\n}"
  }
}
Webhook Returning Data

Custom response:

{
  "path": "my-webhook",
  "httpMethod": "POST",
  "responseMode": "lastNode",  // Return data from last node
  "options": {
    "responseCode": { "values": { "responseCode": 201 } },
    "responseHeaders": {
      "entries": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ]
    }
  }
}

Communication Nodes

Slack (nodes-base.slack)

Popular choice for AI agent workflows

Post Message

Minimal:

{
  "resource": "message",
  "operation": "post",
  "channel": "#general",
  "text": "Hello from n8n!"
}

With dynamic content:

{
  "resource": "message",
  "operation": "post",
  "channel": "={{$json.channel}}",
  "text": "New user: {{$json.name}} ({{$json.email}})"
}

With attachments:

{
  "resource": "message",
  "operation": "post",
  "channel": "#alerts",
  "text": "Error Alert",
  "attachments": [
    {
      "color": "#ff0000",
      "fields": [
        {
          "title": "Error Type",
          "value": "={{$json.errorType}}"
        },
        {
          "title": "Timestamp",
          "value": "={{$now.toLocaleString()}}"
        }
      ]
    }
  ]
}

Gotcha: Channel must start with # for public channels or be a channel ID!

Update Message

Minimal:

{
  "resource": "message",
  "operation": "update",
  "messageId": "1234567890.123456",  // From previous message post
  "text": "Updated message content"
}

Note: messageId required, channel optional (can be inferred)

Create Channel

Minimal:

{
  "resource": "channel",
  "operation": "create",
  "name": "new-project-channel",  // Lowercase, no spaces
  "isPrivate": false
}

Gotcha: Channel name must be lowercase, no spaces, 1-80 chars!

Gmail (nodes-base.gmail)

Popular for email automation

Send Email

Minimal:

{
  "resource": "message",
  "operation": "send",
  "to": "[email protected]",
  "subject": "Hello from n8n",
  "message": "This is the email body"
}

With dynamic content:

{
  "resource": "message",
  "operation": "send",
  "to": "={{$json.email}}",
  "subject": "Order Confirmation #{{$json.orderId}}",
  "message": "Dear {{$json.name}},\n\nYour order has been confirmed.\n\nThank you!",
  "options": {
    "ccList": "[email protected]",
    "replyTo": "[email protected]"
  }
}
Get Email

Minimal:

{
  "resource": "message",
  "operation": "getAll",
  "returnAll": false,
  "limit": 10
}

With filters:

{
  "resource": "message",
  "operation": "getAll",
  "returnAll": false,
  "limit": 50,
  "filters": {
    "q": "is:unread from:[email protected]",
    "labelIds": ["INBOX"]
  }
}

Database Nodes

Postgres (nodes-base.postgres)

Database operations - 456 templates

Execute Query

Minimal (SELECT):

{
  "operation": "executeQuery",
  "query": "SELECT * FROM users WHERE active = true LIMIT 100"
}

With parameters (SQL injection prevention):

{
  "operation": "executeQuery",
  "query": "SELECT * FROM users WHERE email = $1 AND active = $2",
  "additionalFields": {
    "mode": "list",
    "queryParameters": "[email protected],true"
  }
}

Gotcha: ALWAYS use parameterized queries for user input!

// ❌ BAD - SQL injection risk!
{
  "query": "SELECT * FROM users WHERE email = '{{$json.email}}'"
}

// ✅ GOOD - Parameterized
{
  "query": "SELECT * FROM users WHERE email = $1",
  "additionalFields": {
    "mode": "list",
    "queryParameters": "={{$json.email}}"
  }
}
Insert

Minimal:

{
  "operation": "insert",
  "table": "users",
  "columns": "name,email,created_at",
  "additionalFields": {
    "mode": "list",
    "queryParameters": "John Doe,[email protected],NOW()"
  }
}

With expressions:

{
  "operation": "insert",
  "table": "users",
  "columns": "name,email,metadata",
  "additionalFields": {
    "mode": "list",
    "queryParameters": "={{$json.name}},={{$json.email}},{{JSON.stringify($json)}}"
  }
}
Update

Minimal:

{
  "operation": "update",
  "table": "users",
  "updateKey": "id",
  "columns": "name,email",
  "additionalFields": {
    "mode": "list",
    "queryParameters": "={{$json.id}},Updated Name,[email protected]"
  }
}

Storage Nodes

Data Table (nodes-base.dataTable)

Persistent, structured per-project key-value storage — an in-n8n alternative to external SQL for small state like buffers, de-dup sets, counters, or lookup caches. Do not confuse with the MCP tool n8n_manage_datatable — that tool manages tables from outside n8n (create/list/delete tables and rows from Claude). The nodes-base.dataTable node below is what you drop into a workflow to read/write rows during execution.

Verified end-to-end against live n8n on 2026-04-08 with a 15-node assertion harness exercising every claim below: insert returning rows with system id, like operator, returnAll, allConditions AND-of-multiple-filters, isTrue unary boolean condition, upsert with matchingColumns (no duplicates), defineBelow resourceMapper writing values, deleteRows (the reserved-word workaround) returning affected rows, and dataTableId resourceLocator in mode: "name". All 6 assertions passed.

Node shape:

  • type: n8n-nodes-base.dataTable

  • typeVersion: 1.1 (also 1)

  • resource: "row" or "table"

  • Row operation values — note the reserved-word workaround on delete:

    • "insert" — Insert row

    • "get" — Get row(s)

    • "update" — Update row(s) matching conditions

    • "upsert" — Update if match, else insert

    • "deleteRows" — Delete row(s) matching conditions (not "delete" — delete is a JS reserved word, the node uses deleteRows)

    • "rowExists" — Pass through input if at least one match

    • "rowNotExists" — Pass through input if zero matches

Table selection — always a resourceLocator parameter named dataTableId:

"dataTableId": {
  "__rl": true,
  "mode": "list",      // or "name" or "id"
  "value": "dt_xyz123" // or the name when mode=name
}

Row mapping (insert/update/upsert) — resourceMapper parameter named columns:

"columns": {
  "mappingMode": "defineBelow",    // or "autoMapInputData"
  "value": {
    "user_email": "={{ $json.email }}",
    "score": "={{ $json.score }}",
    "active": true
  },
  "matchingColumns": [],           // filled for update/upsert match keys
  "schema": [],                    // n8n re-loads at runtime; safe to leave empty
  "attemptToConvertTypes": false,
  "convertFieldsToString": false
}

In autoMapInputData mode, incoming item field names must match column names exactly and value is ignored.

Filtering (get/update/upsert/deleteRows/rowExists/rowNotExists):

"matchType": "anyCondition",   // or "allConditions"
"filters": {
  "conditions": [
    { "keyName": "user_email", "condition": "eq",        "keyValue": "[email protected]" },
    { "keyName": "score",      "condition": "gte",       "keyValue": 10 },
    { "keyName": "archived",   "condition": "isNotEmpty"  }
  ]
}

Supported condition values: eq, neq, like, ilike, gt, gte, lt, lte, isEmpty, isNotEmpty, isTrue, isFalse. The last four are unary — omit keyValue.

Get options: returnAll: true bypasses the default 50-row limit. options can include ordering.

Insert option: options.optimizeBulk: true skips returning inserted rows for ~5x bulk throughput. Do not use when downstream nodes need the inserted row ids.

Mutating ops (update/upsert/deleteRows) accept options.dryRun: true — returns the rows that would be affected with before/after states, without writing.

Minimal Insert
{
  "resource": "row",
  "operation": "insert",
  "dataTableId": { "__rl": true, "mode": "name", "value": "email_buffer" },
  "columns": {
    "mappingMode": "defineBelow",
    "value": {
      "from_name": "={{ $json.from_name }}",
      "subject":   "={{ $json.subject }}"
    },
    "matchingColumns": [],
    "schema": []
  },
  "options": {}
}
Get All Rows

Get requires at least one condition — a bare "return everything" isn't allowed. Trick: filter on the always-populated system id column with isNotEmpty.

{
  "resource": "row",
  "operation": "get",
  "dataTableId": { "__rl": true, "mode": "name", "value": "email_buffer" },
  "matchType": "anyCondition",
  "filters": {
    "conditions": [ { "keyName": "id", "condition": "isNotEmpty" } ]
  },
  "returnAll": true,
  "options": {}
}
Delete All Rows

Same id isNotEmpty trick — a delete without conditions throws At least one condition is required.

{
  "resource": "row",
  "operation": "deleteRows",
  "dataTableId": { "__rl": true, "mode": "name", "value": "email_buffer" },
  "matchType": "anyCondition",
  "filters": {
    "conditions": [ { "keyName": "id", "condition": "isNotEmpty" } ]
  },
  "options": {}
}
Upsert by Natural Key
{
  "resource": "row",
  "operation": "upsert",
  "dataTableId": { "__rl": true, "mode": "name", "value": "user_scores" },
  "matchType": "allConditions",
  "filters": {
    "conditions": [ { "keyName": "user_email", "condition": "eq", "keyValue": "={{ $json.email }}" } ]
  },
  "columns": {
    "mappingMode": "defineBelow",
    "value": {
      "user_email": "={{ $json.email }}",
      "score":      "={{ $json.score }}"
    },
    "matchingColumns": ["user_email"],
    "schema": []
  },
  "options": {}
}

System columns: every table auto-has id plus created/updated timestamps — you don't declare these and can't write to them. They're usable in filters.

When to reach for Data Table vs alternatives:

NeedUse
Small per-workflow scratch state, single workflow, not durable across workflow edits$getWorkflowStaticData('global') inside a Code node
Persistent structured state, queryable by column, survives workflow rename/edit/deactivation, shared across multiple workflows in the same projectData Table node
Large datasets (>>10k rows), complex joins, transactions, FKs, indexesExternal Postgres/MySQL
Unstructured key-value cache with TTLRedis

Gotchas:

  • Scope is per project — Data Tables are not shared across n8n projects. Move a workflow to another project and its Data Table references break.

  • Filter operator eq on a column that doesn't exist in the table returns a validation error at execution, not at import — always verify column names match the live table.

  • Expression values in columns.value are evaluated per input item. If the upstream node emits N items, Insert runs N times unless you explicitly use optimizeBulk.

  • deleteRows is the operation value, not delete. Using delete will import but fail at execution with "unknown operation".

  • Race condition in buffer/flush patterns: rows added between Get and deleteRows will be wiped without being read. For at-least-once semantics, delete by specific row ids returned from Get instead of by a broad filter.

  • Zero-match halts the chain. When get, deleteRows, update, or upsert matches 0 rows, the node emits 0 output items and n8n stops the downstream branch silently — no error, just nothing happens. This bites cleanup steps in idempotent test/setup workflows where the table starts empty. Fix: set node-level "alwaysOutputData": true (sibling of parameters/type, NOT inside parameters) on any DT node that may legitimately match nothing. The node will then emit a single empty item and the chain continues.

  • DT operations execute once per input item. A Get node fed 3 input items will run 3 separate queries and concatenate the results — usually not what you want. Set the node-level "executeOnce": true (sibling of parameters) on a DT op that should run exactly once; it runs on the first input item only. No "collapse" Code node is needed.

Data Transformation Nodes

Set (nodes-base.set)

Most used transformation - 68% of workflows!

Set Fixed Values

Minimal:

{
  "mode": "manual",
  "duplicateItem": false,
  "assignments": {
    "assignments": [
      {
        "name": "status",
        "value": "active",
        "type": "string"
      },
      {
        "name": "count",
        "value": 100,
        "type": "number"
      }
    ]
  }
}
Set from Input Data

Mapping data:

{
  "mode": "manual",
  "duplicateItem": false,
  "assignments": {
    "assignments": [
      {
        "name": "fullName",
        "value": "={{$json.firstName}} {{$json.lastName}}",
        "type": "string"
      },
      {
        "name": "email",
        "value": "={{$json.email.toLowerCase()}}",
        "type": "string"
      },
      {
        "name": "timestamp",
        "value": "={{$now.toISO()}}",
        "type": "string"
      }
    ]
  }
}

Gotcha: Use correct type for each field!

// ❌ Wrong type
{
  "name": "age",
  "value": "25",      // String
  "type": "string"    // Will be string "25"
}

// ✅ Correct type
{
  "name": "age",
  "value": 25,        // Number
  "type": "number"    // Will be number 25
}
Code (nodes-base.code)

JavaScript execution - 42% of workflows

The two examples below only show the Code node's config shape. Both jobs are Edit Fields expressions in a real workflow ({{ $json.name.toUpperCase() }}). A new Code node has to pass the gate in n8n-code-javascript and carries "notes": "Why Code: <native node considered> — <reason>". Native transform configs: NATIVE_NODES.md.

Simple Transformation

Minimal:

{
  "mode": "runOnceForAllItems",
  "jsCode": "return $input.all().map(item => ({\n  json: {\n    name: item.json.name.toUpperCase(),\n    email: item.json.email\n  }\n}));"
}

Per-item processing:

{
  "mode": "runOnceForEachItem",
  "jsCode": "// Process each item\nconst data = $input.item.json;\n\nreturn {\n  json: {\n    fullName: `${data.firstName} ${data.lastName}`,\n    email: data.email.toLowerCase(),\n    timestamp: new Date().toISOString()\n  }\n};"
}

Gotcha: In Code nodes, use $input.item.json or $input.all(), NOT {{...}}!

// ❌ Wrong - expressions don't work in Code nodes
{
  "jsCode": "const name = '={{$json.name}}';"
}

// ✅ Correct - direct access
{
  "jsCode": "const name = $input.item.json.name;"
}

Conditional Nodes

IF (nodes-base.if)

Conditional logic - 38% of workflows

String Comparison

Equals (binary):

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.status}}",
        "operation": "equals",
        "value2": "active"
      }
    ]
  }
}

Contains (binary):

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.email}}",
        "operation": "contains",
        "value2": "@example.com"
      }
    ]
  }
}

isEmpty (unary):

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.email}}",
        "operation": "isEmpty"
        // No value2 - unary operator
        // singleValue: true added by auto-sanitization
      }
    ]
  }
}

Gotcha: Unary operators (isEmpty, isNotEmpty) don't need value2!

Number Comparison

Greater than:

{
  "conditions": {
    "number": [
      {
        "value1": "={{$json.age}}",
        "operation": "larger",
        "value2": 18
      }
    ]
  }
}
Boolean Comparison

Is true:

{
  "conditions": {
    "boolean": [
      {
        "value1": "={{$json.isActive}}",
        "operation": "true"
        // Unary - no value2
      }
    ]
  }
}
Multiple Conditions (AND)

All must match:

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.status}}",
        "operation": "equals",
        "value2": "active"
      }
    ],
    "number": [
      {
        "value1": "={{$json.age}}",
        "operation": "larger",
        "value2": 18
      }
    ]
  },
  "combineOperation": "all"  // AND logic
}
Multiple Conditions (OR)

Any can match:

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.status}}",
        "operation": "equals",
        "value2": "active"
      },
      {
        "value1": "={{$json.status}}",
        "operation": "equals",
        "value2": "pending"
      }
    ]
  },
  "combineOperation": "any"  // OR logic
}
Switch (nodes-base.switch)

Multi-way routing - 18% of workflows

Basic Switch

Minimal:

{
  "mode": "rules",
  "rules": {
    "rules": [
      {
        "conditions": {
          "string": [
            {
              "value1": "={{$json.status}}",
              "operation": "equals",
              "value2": "active"
            }
          ]
        }
      },
      {
        "conditions": {
          "string": [
            {
              "value1": "={{$json.status}}",
              "operation": "equals",
              "value2": "pending"
            }
          ]
        }
      }
    ]
  },
  "fallbackOutput": "extra"  // Catch-all for non-matching
}

Gotcha: Number of rules must match number of outputs!

AI Nodes

OpenAI (nodes-langchain.openAi)

AI operations - 234 templates

Chat Completion

Minimal:

{
  "resource": "chat",
  "operation": "complete",
  "messages": {
    "values": [
      {
        "role": "user",
        "content": "={{$json.prompt}}"
      }
    ]
  }
}

With system prompt:

{
  "resource": "chat",
  "operation": "complete",
  "messages": {
    "values": [
      {
        "role": "system",
        "content": "You are a helpful assistant specialized in customer support."
      },
      {
        "role": "user",
        "content": "={{$json.userMessage}}"
      }
    ]
  },
  "options": {
    "temperature": 0.7,
    "maxTokens": 500
  }
}

Schedule Nodes

Schedule Trigger (nodes-base.scheduleTrigger)

Time-based workflows - 28% have schedule triggers

Daily at Specific Time

Minimal:

{
  "rule": {
    "interval": [
      {
        "field": "hours",
        "hoursInterval": 24
      }
    ],
    "hour": 9,
    "minute": 0,
    "timezone": "America/New_York"
  }
}

Gotcha: Always set timezone explicitly!

// ❌ Bad - uses server timezone
{
  "rule": {
    "interval": [...]
  }
}

// ✅ Good - explicit timezone
{
  "rule": {
    "interval": [...],
    "timezone": "America/New_York"
  }
}
Every N Minutes

Minimal:

{
  "rule": {
    "interval": [
      {
        "field": "minutes",
        "minutesInterval": 15
      }
    ]
  }
}
Cron Expression

Advanced scheduling:

{
  "mode": "cron",
  "cronExpression": "0 */2 * * *",  // Every 2 hours
  "timezone": "America/New_York"
}

Summary

Key Patterns by Category:

CategoryMost CommonKey Gotcha
HTTP/APIGET, POST JSONRemember sendBody: true
WebhooksPOST receiverData under $json.body
CommunicationSlack postChannel format (#name)
DatabaseSELECT with paramsUse parameterized queries
TransformSet assignmentsCorrect type per field
ConditionalIF string equalsUnary vs binary operators
AIOpenAI chatSystem + user messages
ScheduleDaily at timeSet timezone explicitly

Configuration Approach:

  1. Use patterns as starting point

  2. Adapt to your use case

  3. Validate configuration

  4. Iterate based on errors

  5. Deploy when valid

Related Files:

Worked Example: Configuring HTTP Request Step by Step

A full validate-driven walkthrough of building a POST JSON request from minimal config, letting validation surface each required field.

Step 1: Identify what you need

// Goal: POST JSON to API

Step 2: Get node info

const info = get_node({
  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({
  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({...});
// → 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({...});
// → Valid! ✅

Operation-Specific Configuration Examples

Concrete minimal configs showing how required fields differ by resource + operation.

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": "[email protected]"
    }
  }
}
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
      }
    ]
  }
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Romuald Czlonkowski
Publisher
Romuald Czlonkowski (Community)
Source
czlonkowski/n8n-skills · skills/n8n-node-configuration · commit e037563
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Romuald Czlonkowski.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download n8n-node-configuration.zip