n8n Templates: How to Find, Import and Adapt Them Safely

Last verified: October 2026

n8n templates are ready-made workflows you import as JSON and adapt. The official library lists more than 13,000 of them, built mostly by the community, and any workflow JSON from a forum post or a colleague works the same way. Credentials never travel with a template, so importing one is safe; running it unread is not.

That last sentence is the whole post. Templates save hours when you treat them as a starting point and cost you an afternoon (or a customer list) when you treat them as finished software. Here is how to find them, get them into your instance, and adapt them without surprises.

Where to find n8n templates: the n8n template library

The n8n template library is the official source. On 20 October 2026 the page heading showed 13,487 templates. You can search and filter the library, and each template page shows the canvas, a description and the nodes it uses.

Three other sources are worth knowing:

• Inside the editor. On a fresh canvas, n8n offers templates directly, and the integration pages in the editor link to templates that use that node. Same library, fewer clicks.
• The community forum. Posts on community.n8n.io often include full workflow JSON in a code block as part of a question or an answer. These are not reviewed and often reflect an older version of n8n, which matters later.
• Other people's exports. Any JSON file downloaded from an n8n instance is a template in all but name. This is how workflows move between a test instance and production, or from an agency to a client.

If you want a shortlist of n8n workflow templates that are worth starting with, the n8n workflow examples post picks eight common shapes and explains what each one does. This post is about the mechanics of using any template, not a list.

How to import n8n template JSON: five routes

Every import route ends in the same place: a new or existing workflow with the template's nodes on the canvas. The route you choose depends on where the JSON is.

The last row is the one people miss. If you copy a workflow's JSON and paste it onto an existing canvas with the keyboard shortcut, the nodes land next to whatever is already there. That is how you combine two templates, or lift three nodes out of one into another.

After any import, n8n shows warnings on nodes that need credentials you have not attached. That is expected. Nothing has run yet.

Credentials never travel with n8n workflow templates

Open any exported workflow in a text editor and look at a node that talks to a service. You will see something like this:

{
  "parameters": {
    "resource": "message",
    "operation": "post",
    "channel": "#alerts",
    "text": "={{ $json.summary }}"
  },
  "name": "Post to Slack",
  "type": "n8n-nodes-base.slack",
  "typeVersion": 2.2,
  "position": [720, 300],
  "credentials": {
    "slackApi": {
      "id": "k3Qx9mPz2LwVbN7a",
      "name": "Slack account"
    }
  }
}

The credentials block holds an ID and a display name. That is a pointer to a credential record on the instance the workflow came from. The token itself lives in n8n's encrypted credentials table and is never written into a workflow export. When you import this node, n8n looks for a credential with a matching ID or name on your instance, and if there is none the node shows a warning until you pick or create one.

Two consequences:

• You can share a workflow export without leaking secrets. The only risk is secrets you typed directly into a parameter field, such as an API key pasted into an HTTP Request header instead of a credential. Search the JSON for anything that looks like a key before you share it.
• Moving between instances goes faster if you name credentials consistently. A credential called "Slack account" on both instances attaches without a click.

There is one exception worth knowing. Expressions and Code nodes can contain anything the author typed, including hard-coded URLs, email addresses and occasionally a token. That is why the next step exists.

Read before you run: what to check in n8n templates

A template is someone else's code. You would not run a shell script from a forum without reading it, and a workflow deserves the same two minutes. Check these, in order:

1. The trigger. A Schedule Trigger starts running on its own the moment you publish. A Webhook needs a caller. A polling trigger will process everything it considers "new" on first run, which on a Sheets trigger can mean every row.
2. Every node that writes. Send, create, update, delete, post. Each of those is where the template touches the world. Note each one and decide whether it should point at a test destination first: a test channel, a copy of the sheet, a sandbox API key.
3. Every Code node. Read the whole thing. This is the one place where a template can do something the canvas does not show. Since n8n 2.0, Code nodes cannot read environment variables by default and run on task runners, so older templates that relied on process.env or $evaluateExpression() will fail rather than misbehave, which is the better failure.
4. Hard-coded values. Channel names, sheet IDs, email addresses, URLs. Each one is a value the author set for their own setup. Find them with a search for http, @ and # in the JSON.
5. Loop and batch sizes. A Loop Over Items with no wait between batches, pointed at an API with a rate limit, will get your key throttled on the first run.

Then run it once manually, with the trigger's sample data or a single test item, and read the execution node by node. If the execution log shows 400 items heading into a Gmail node, stop there. The n8n workflows explainer covers how to read items and executions if that view is new to you.

Adapting a template without breaking it

Most adaptation is substitution: your sheet for theirs, your channel for theirs, your field names for theirs. The field names are where it goes wrong, because expressions downstream reference them by name. Change the column header from Email to email_address in the sheet and every {{ $json.Email }} in the workflow now resolves to nothing, and the workflow stops silently when a node gets zero items.

A method that avoids most of it:

• Put an Edit Fields node right after the trigger that maps your field names onto the names the template expects. The rest of the template stays untouched and still works.
• Replace one node at a time and run manually after each replacement. Replacing five nodes and then debugging is slower than it sounds.
• Keep the original import as a separate, unpublished workflow named "Template: original". When your adapted version misbehaves, diff against it.
• Add an error workflow before publishing. Templates almost never ship with one, and the n8n error handling post shows the five-minute version.

If the template uses a service you do not, swapping is usually possible. A Slack node and a Telegram node both take a text field and a destination; the n8n integrations pages list the common swaps and what each node expects. Sheets-based templates are the easiest to adapt because the schema is visible; the Google Sheets integration page covers the append versus update operations that templates most often get wrong.

Versions, typeVersion and breaking changes

Every node in a template carries a typeVersion. It pins which version of that node's parameters and behaviour the template was built against. n8n keeps old node versions around, so a template built on Slack node 2.1 still works when your instance ships 2.3; it simply uses 2.1. This is why five-year-old templates often import cleanly.

The other direction fails. A template exported from n8n 2.43 using a node version your 1.x instance has never heard of will import with errors or not at all. Update first; the how to update n8n post covers doing that without losing anything.

Major versions are where templates actually break. The n8n 2.0 breaking changes removed the Start node (older templates begin with one; replace it with a Manual Trigger), removed the Pyodide-based Python Code node (Python now needs external task runners), blocked environment variable access from Code nodes by default, disabled the Execute Command and Local File Trigger nodes by default, and removed the nodes for a handful of retired services. A template that uses any of those will import but will not run as written. The forum is full of templates from 2023 and 2024 that hit exactly this.

Practical rule: check the template's date before its star count. A template updated this year against the current version saves you an hour of archaeology that a more popular one from 2024 would cost.

When n8n templates are the wrong starting point

Templates are great for learning a node you have not used and for the eighty percent of workflows that are a known shape (sync, alert, intake, enrich). They are a poor fit when:

• Your data model is unusual. Adapting a template built on a different schema takes longer than building from the trigger up.
• The template is mostly Code nodes. At that point you are maintaining someone else's script with extra steps.
• You cannot explain what each node does. If you cannot, you cannot fix it when it breaks at 2 a.m., and it will.

One more consideration for Cloud users: templates that rely on community nodes will not work on n8n Cloud unless the node is one of the verified ones, and templates that assume server access (reading local files, running shell commands) will not work there at all. If a template you need depends on either, that is a reason to look at n8n Cloud vs self-hosted before you spend time adapting it. A self-hosted instance on Docker runs anything the template asks for, at the cost of you running the server.

Used with that two-minute read, templates are the fastest way into n8n I know. Skip the read and they are the fastest way to an apology email.