Should Your SaaS Build an n8n Integration?

If you run a software product, you've probably had this email: "Do you support n8n?" Then another, and a third.

You start typing the honest answer, "Well, you can use the HTTP Request node, and read our API docs, and…", and you can feel how that sounds.

This guide lays out your options, what each one gets your customers, and when the right answer is to not build anything at all.

What your customer does today

Without a node, your customer uses n8n's HTTP Request node, which can call any API, and it's very good. So your product is never out of reach.

Look at what they're doing, though. Reading your API docs. Working out where the key goes. Building the request body by hand. Finding out the hard way that your list endpoint only returns the first page.

Some of your customers will happily do that; they're developers. The ones writing to you are usually the ones who aren't.

The four options

From least work to most:

1. Docs and a template. A page that shows how to call your API from n8n, and a workflow people can copy. It costs an afternoon. It doesn't fix much, and it's better than nothing.

2. A community node. Your own node, published to npm, that anyone running their own n8n can install. Now your product shows up as itself: your logo, your login form, and dropdowns instead of raw requests.

3. A verified community node. The same node, reviewed and approved by n8n. This is where it gets interesting; more below.

4. A built-in n8n node. People ask about getting into n8n's own nodes. That's n8n's decision, not yours. The first three are all in your hands.

	Docs and template	Community node	Verified community node
Self-hosted n8n	yes, by hand	yes, installed by package name	yes, from the nodes panel
n8n Cloud	yes, by hand	no	yes
Your logo and login form	no	yes	yes
Found by searching in n8n	no	no	yes

Why verified matters

Here's what most founders don't know. A lot of n8n users don't run their own server; they use n8n Cloud. On Cloud, people can install verified community nodes, and only verified ones. An unverified node isn't available to them at all.

So if your node isn't verified, a whole group of your customers can't use it, however good it is.

That group grows with n8n 3.0, which turns off unverified community nodes by default on self-hosted instances.

Verified nodes also get found. They appear when someone searches n8n's nodes panel, and since n8n 2.33 they're listed when someone picks tools for an AI agent, before anyone has installed them.

So if you're going to build a node, plan for verification from day one. It has rules, and some are far easier to follow from the start than to fix later: publishing from GitHub Actions with provenance, and no run-time dependencies, among others. The verification guide lists them all.

What it really costs

Building it. Credentials, every operation, pagination, error messages, the wording n8n expects. It's real work, and it's what the ten-part Build your own n8n node series goes through, step by step.

Verification. A review against n8n's guidelines, a publishing setup with provenance, and a rule against run-time dependencies.

Keeping it working. It never quite ends. Your API will change, and each time it does, the node has to change without breaking the workflows your customers already saved. Node versioning is how.

None of it is hard on its own. Together, it's a small product you now maintain. For agency prices and review times across n8n, Zapier, Make and Activepieces, see what an integration costs in 2026.

When not to build one

• You've had two or three of these emails, and that's it. Write the docs page and a template first, and see if more people come.
• You don't have a stable public API yet. A node wraps your API. Build the API first.
• Your API changes every week. You'll spend more time updating the node than your customers spend using it.

But if the emails keep coming, and your customers would rather click than write requests, a verified node is one of the cheapest ways to show up where they already work.

Recap

• Your customers can already reach you through HTTP Request, but it's hard work for them.
• n8n Cloud users can only install verified community nodes.
• A node is something you keep working, not something you ship once.
• Not sure yet? Start with docs and a template.

One more thing. If you have an OpenAPI spec, NativeShip, the tool we build, turns it into an n8n node package you publish under your own name. That's the build step, done from what you already have.