Types of n8n Nodes: Trigger Nodes, Action Nodes & Core Nodes

n8n organizes every node into four architectural categories defined by the INodeType interface contract. Trigger nodes initiate workflows and have no input connections. App/Action nodes integrate external services with resource‑operation structures. Core nodes provide generic data transformation and flow control without external dependencies. Cluster nodes implement interconnected sub‑node composition patterns, primarily for AI and LangChain workflows. This guide catalogs every node type, their activation modes, and configuration signatures.

What are n8n trigger nodes and how do they activate workflows?

Trigger nodes are the sole entry point of every n8n workflow—they define inputs: [], explicitly disallowing any upstream connection, and implement event‑listener or polling mechanisms that fire when a specific condition is met. The platform supports webhook triggers (incoming HTTP requests), schedule triggers (cron‑based time activation), app event triggers (service‑native events), and manual triggers (on‑demand execution). [1]

For a complete taxonomy of every trigger type, their activation mechanisms, and execution modes, see the n8n trigger nodes guide.

How do you configure the Webhook node’s authentication, response mode, and payload handling?

The Webhook node exposes a unique URL that listens for incoming HTTP POST or GET requests. It supports four authentication methods—HMAC‑SHA256 signature verification, Basic Auth, Header Auth, and JWT—plus three response modes: immediate, using a Respond to Webhook node, or waiting for workflow completion. The “Raw Body” option preserves the unparsed payload for cryptographic validation. [5]

For a complete walkthrough of webhook configuration covering HTTP methods, authentication setup, payload parsing, response routing, and IP allowlisting, see the n8n Webhook node configuration guide.

What are action nodes and how do they connect n8n to external services?

Action nodes—also called App nodes—connect n8n to external services by implementing a resource‑operation parameter structure. Each node exposes multiple operations: Read (fetch data), Write (create/update records), Delete (remove records), and specialized actions like Send Message or Create Ticket. The node’s credential panel handles OAuth2, API key, or Basic Auth authentication automatically. [2]

Action nodes span CRM systems (HubSpot, Salesforce), messaging platforms (Slack, Teams), databases (Postgres, MySQL), cloud storage (Drive, S3), and developer tools (GitHub, GitLab, Jira). For the full catalog organized by service category, see the n8n integration nodes catalog.

How do core nodes provide data transformation and flow control without external dependencies?

Core nodes implement generic workflow operations that require no external service credentials. IF and Switch nodes route data conditionally across branches; Merge nodes combine multiple streams; Set and Code nodes transform JSON structures; the Error Trigger node catches failures; and the SplitInBatches node processes large datasets in controlled chunks. [6]

For detailed configuration of IF and Switch routing nodes, see the IF & Switch node branching guide.

How does the Error Trigger node catch failures and initiate retry or alert workflows?

The Error Trigger node must be the first node in a dedicated error workflow. When any production workflow fails, n8n sends a structured JSON payload containing execution.id, error.message, lastNodeExecuted, and the full stack trace into this node. You chain Slack, email, or retry logic downstream to respond to the failure automatically. [7]

For a complete guide to error workflow setup, retry configuration, exponential backoff strategies, and alert integration, see the n8n error handling nodes guide.

How does the SplitInBatches node loop over items with configurable batch size and iteration?

The SplitInBatches node divides an incoming list into smaller batches of a fixed size and outputs one batch at a time through its loop port. After processing, you connect back to the node to fetch the next batch, repeating until all items are exhausted and the done port fires. A practical starting point is 10–50 items per batch for API‑heavy work and 100–500 for lightweight transforms. [8]

For full documentation covering batch size selection, loop configuration, rate‑limit avoidance, paginated API handling, and progress checkpointing, see the n8n SplitInBatches node guide.