n8n Integration Nodes: Apps, APIs, and Data Sources Explained

An integration node is the bridge between n8n and another system. It can read data, send data, or ask a service to perform an action. The useful question is not “Which node is the most powerful?” It is “Where does this workflow need a reliable connection?”

What does an n8n integration node do?

An integration node talks to an app or data source through a supported operation. A Gmail node can read messages. A database node can run a query. An HTTP Request node can call an API that does not have a dedicated integration.

Each node usually has four parts: credentials, an operation, input fields, and output data. Keep those parts visible while you build. A small, testable request is easier to fix than a large request hidden inside a long workflow.

How should you choose the connection?

Start with the service that owns the data. Use a dedicated app node when the operation is common and the node exposes the fields you need. Use HTTP Request when the API is new, unusual, or only partly supported by a dedicated node.

A database node is a better fit when the workflow needs joins, filters, or transactions. A data transformation node is useful after the connection succeeds. It keeps transport work separate from business rules.

You can compare these roles in the n8n node type guide. The trigger-node guide explains how data enters the workflow before an integration node acts on it.

What should you test first?

Test authentication before testing the whole workflow. Then request one small record. Check the field names, data types, empty values, and pagination behavior. These checks reveal most integration mistakes early.

A good first test answers three simple questions:

• Can n8n authenticate without exposing the secret in the workflow?
• Does the response contain the field the next node needs?
• What should happen when the service returns no record or an error?

Write down the answer in the node description or a nearby note. Future changes become much easier to review.

How do credentials fit into the design?

Credentials should live in n8n’s credential store. The workflow should refer to a credential, not repeat its token in a text field. Give each credential a clear environment name, such as production-crm-read or staging-database-write.

Use the smallest permission set that supports the operation. A read-only workflow does not need a write token. Rotate credentials when an owner, environment, or service policy changes.

What happens when an API is not supported?

The HTTP Request node is the practical fallback. Read the service’s API documentation first. Confirm the URL, method, authentication scheme, request body, response format, and rate limit. Then place the request in a small test workflow.

Keep the raw response near the request while debugging. Once the shape is stable, add a transformation node and pass only the fields that later steps need.

A calm operating pattern

Let one node connect. Let the next node validate. Let later nodes transform or publish. This separation makes an automation easier to read and gives each failure a clear location.

For current integration behavior, consult the official n8n integrations documentation.