How to Get Your n8n Community Node Verified

This is the written version of Part 8 of Build your own n8n node. There's a short form in n8n's Creator Portal with one field and a Submit button. Pressing it sends your node to a person at n8n for review, and it feels like handing in homework.

On the other side of it is your node in n8n's own nodes panel, with a badge, on n8n Cloud too. This part goes through everything the reviewer looks at, before you press it. Most of it you've already done. One item is a single line in package.json that you probably added without thinking, and it's enough to get the node sent back.

Why it's worth it

Without verification, using your node means a customer has to find out it exists, open Settings, type a package name and install it. On n8n Cloud they can't install it at all, because Cloud only allows verified community nodes.

With verification, they search the nodes panel, and your node is there with a badge. That's the difference between "we have an n8n node, here's a guide to installing it" and "just search for us."

The ones you've already done

If you followed the series, these are ticked:

• Built with n8n's tool. n8n asks verified node authors to use n8n-node to create and check the package. That was Part 2.
• The linter passes. Part 7.
• Published from GitHub Actions with provenance, from a public repository. Also Part 7.

Three ticks, and nothing new to do today. That's what the earlier work was for.

Run n8n's own scan

n8n's verification guidelines name one more check, which runs against the package as published on npm:

npx @n8n/scan-community-package n8n-nodes-acme-crm

Run it before you submit, and fix whatever it reports.

The README

Be honest: is yours still the template text? Mine usually is at this point.

It doesn't need to be long. It needs:

• what the node does, and for which product
• how to connect an account: where to get an API key, or how to set up OAuth2
• which resources and operations it supports
• a link to your API's documentation, and an example workflow if you have one

Write it for the person who has just installed the node and has no idea what to do next. That's also the person reviewing it.

The big one: no run-time dependencies

This is the one that surprises people. A verified node can't depend on any other package when it runs. None.

It's easy to break without noticing. Back in Part 5 you needed one small helper, a date library maybe, and installed a package for it without a second thought. Everyone does. That one line under dependencies in package.json is enough to get the node sent back.

"dependencies": {
  "some-helper": "^2.1.0"
}

Why so strict? The same reason as provenance. A node runs right next to people's API keys, and every package you add brings its own packages, which bring theirs. That's a lot of strangers' code next to someone's keys.

So dependencies has to be empty. Tools under devDependencies are fine, because they're used to build the node and aren't installed with it, and n8n-workflow is a peer dependency that n8n itself provides. And the thing you installed a whole package for, you can nearly always write yourself in a few lines.

The quieter rules

From n8n's verification guidelines:

• No environment variables, no file system. The node must not read environment variables or read or write files. Everything it needs comes through its own fields and its credentials.
• English only. Labels, descriptions, error messages and the README.
• MIT licence.
• The repository matches. The repository URL on npm must point at the public GitHub repository, and the author or maintainer should match between npm and GitHub.
• One service per package. A package that wraps several unrelated APIs, or acts as a proxy for several services, doesn't qualify. A trigger node for the same service can sit alongside the main node; it has to be programmatic.
• Not an existing node. If n8n already has a node for the service, improve that one with a pull request instead. n8n also isn't accepting logic or flow-control nodes at the moment, and reserves the right to reject nodes that compete with its paid features.
• The UX guidelines. Everything from Part 6: n8n's operation names, password fields for keys, the resource locator, { "deleted": true }.

And one that's more common sense than rule: the node should do what it says, for the product it's named after, with no surprises inside.

Submit

When everything's ticked, sign up or sign in to the n8n Creator Portal (linked from n8n's submission docs), put in your package name and submit. n8n fetches the package from npm for its final checks.

Then you wait. n8n doesn't publish a review time, because it depends on how many nodes are in the queue ahead of yours. Make and Zapier reviews queue up too; if you're shipping there as well, here's how to unblock a stuck Make or Zapier review.

What comes back

One of two things.

They say yes. Or they send a list of changes.

The first time you get the second one, your stomach drops and you read it as "no." It isn't. It's a list of fixes: somebody looked at your node carefully and told you exactly what to change. That's a kind thing to get.

So you fix what's on the list, publish a new version the same way as before, and send it back. That's normal, and it's how it goes for a lot of people.

The badge

Then one day it's there. You open n8n, search, and your node is in the list with a badge. On Cloud, for everyone.

What you can do now:

• run the reviewer's checklist yourself, before they do
• submit through the Creator Portal
• treat requested changes as a list to work through

Most series stop here. But three months from now somebody on your team renames a field in the API, and every workflow your customers built sits on this node. In Part 9 you ship that change and their workflows keep running.

One more thing. NativeShip, the tool we build, generates nodes with no run-time dependencies, checks each build with n8n's linter, and publishes from GitHub Actions with provenance, so the package starts out on the right side of these rules. The review itself is still yours to submit.