n8n Integrations: Setup Guides for the Top Apps

How n8n integrations actually work

An integration in n8n is a node: a block you drop on the canvas that knows how to talk to one service. Most nodes come in two flavours. A trigger node starts a workflow when something happens in that service, such as a message arriving or a row being added. An action node does something there, such as sending a message or updating a record. A single workflow usually chains one trigger to several actions across different services.

Credentials are stored separately from workflows, which is worth understanding early. You authenticate once against a service, and every node that needs it reuses that stored credential. That is why exported workflow JSON can be shared safely: the credentials do not travel with it, and whoever imports it attaches their own.

When there is no node for your service

This is the question people ask after the first week, and the answer is the reason n8n scales further than most no-code tools. Three fallbacks, in order of how often they are the right one.

The HTTP Request node talks to any REST API. If a service has documented endpoints, you can use it in n8n today whether or not a dedicated node exists. In practice this covers the long tail of internal tools and smaller SaaS products that will never get a purpose-built node.

The Webhook node handles the other direction, giving you a URL that any service can call to start your workflow. Between those two nodes, most "is X supported?" questions become yes.

Community nodes fill the gap where someone has already done the work. They install into a self-hosted instance and are maintained by their authors rather than by n8n, which is the trade: broader coverage, and a dependency that may lag behind a major version upgrade. Check that anything you rely on supports your target version before upgrading.

Billing is per workflow run, not per step

This changes how you design integrations compared with task-billed tools. On n8n, one run of a workflow counts as one execution whether that workflow touches two services or twenty. There is no cost pressure to collapse steps, so you can add logging, error branches and validation nodes freely. On Zapier, where each successful action step is a billable task, the same instinct gets expensive quickly. If you are coming from that model, the habit of minimising steps is one you can safely unlearn.

Testing before you trust it

Every integration page here ends with an importable workflow, and the right way to use one is to run it manually in the editor first. Manual runs do not count against a Cloud plan's execution allowance, so you can step through the nodes, inspect the data at each stage and fix the credential mapping at no cost before switching the workflow on. Once it is active, check the executions list after the first real trigger rather than assuming it worked. The gap between "the test run passed" and "the production trigger fired correctly" is where most integration problems live.

Picking your first one

The integrations below are the ones people reach for first, each with credential setup, a worked example and an importable workflow. If you are automating team communication, start with Slack or Telegram. For data, Google Sheets is the usual first stop and doubles as a quick database. For anything involving models, OpenAI is the common entry point. And if you are wiring up a service with no node of its own, go straight to webhooks.