n8n Verified Community Node Checklist (2026)

To get an n8n community node verified, you publish it to npm as an n8n-nodes- package with no runtime dependencies. It has to pass n8n's linter and @n8n/scan-community-package, follow n8n's UX guidelines, and come with a README. Then you submit it through the n8n Creator Portal. Since May 1, 2026, n8n also requires the npm release to come from a GitHub Actions workflow with an npm provenance statement. A package published from a laptop won't be accepted for verification.

Verification matters because verified nodes are the ones users can find and install from the nodes panel inside n8n. That includes n8n Cloud, and n8n's official starter repo presents verification as the way to make a node available there. This guide covers every requirement, links to the n8n documentation behind it, and says plainly where the docs leave something undocumented.

The checklist

Use this as a pre-submission check. Each item is explained below.

Package and structure

• Package name is n8n-nodes-<name> or @<scope>/n8n-nodes-<name>
• keywords includes n8n-community-node-package
• Nodes and credentials are registered in the n8n attribute of package.json
• Project was scaffolded with the n8n-node CLI (npm create @n8n/node), and strict mode is on
• The package integrates a single third-party service (a trigger node for that same service is allowed)
• It isn't a duplicate of an existing node, and it isn't a logic or flow-control node
• License is MIT

Code

• dependencies in package.json is empty (no runtime dependencies)
• The code doesn't read environment variables or touch the file system
• Written in TypeScript, with proper error handling
• npm run lint passes
• npx @n8n/scan-community-package <your-package> passes
• The node follows n8n's UX guidelines (password fields for secrets, OAuth if available, CRUD operations, Title Case and Sentence case)
• Everything is in English: the UI, error messages and README

Publishing

• The repo is public on GitHub, and the npm repository URL points to it
• The author or maintainer matches between npm and GitHub
• Releases are published by a GitHub Actions workflow with npm provenance
• @n8n/node-cli is version 0.23.0 or later in devDependencies

Submission

• The README covers setup, authentication, operations and example usage
• The node is submitted at creators.n8n.io/nodes
• It doesn't compete with n8n's paid or enterprise features

Package naming, keywords and the n8n attribute

Community nodes are ordinary npm packages, and n8n finds them by naming convention. The submission docs require:

• a package name starting with n8n-nodes- or @<scope>/n8n-nodes-, for example n8n-nodes-weather or @weatherPlugins/n8n-nodes-weather
• n8n-community-node-package in keywords
• every node and credential file listed inside the n8n attribute of package.json

For a SaaS company, a scoped name under your own npm org (for example @yourcompany/n8n-nodes-yourcompany) makes it obvious the package is official.

Start from the n8n-node scaffolding

n8n "strongly suggests" scaffolding any node you plan to submit with the n8n-node CLI. It isn't strictly mandatory, but the verification guidelines say all verified-node authors should use it. The CLI generates the expected file structure and package.json metadata, wires up linting, and runs a local n8n with your node loaded:

npm create @n8n/node      # scaffold a new package
npm run dev               # local n8n at localhost:5678 with your node loaded
npm run lint              # n8n's lint rules
npm run release           # bump version, tag, push (triggers the publish workflow)

The scaffold sets "strict": true in the n8n block of package.json. According to the CLI's README, strict mode enforces the default ESLint config and the community node rules needed for n8n Cloud verification. If you run n8n-node cloud-support disable to customise ESLint, the node is no longer eligible.

The guidelines also limit what a package can contain:

• One service per package. Packages that wrap several unrelated APIs, or act as a proxy for several services, mostly don't qualify.
• A trigger is allowed. You can ship a trigger node for the same service. It has to be written in the programmatic style, because the declarative style doesn't support triggers. Declarative action nodes and programmatic trigger nodes can live in the same package.
• No duplicates. If your node improves an existing one, n8n asks for a pull request instead.
• No logic or flow-control nodes for now.

Pass the linter and the community package scanner

You need two automated checks to pass:

1. npm run lint (or n8n-node lint) runs n8n's ESLint plugin for community nodes. Its rules include no-runtime-dependencies, credential-test-required (every credential needs a test), credential-password-field (sensitive fields must be password fields), no-dangerous-functions (no eval or child_process), no-hardcoded-secrets, no-forbidden-lifecycle-scripts (no postinstall and similar), valid-peer-dependencies (only n8n-workflow as a peer), and package-name-convention. npm run lint:fix fixes some of these automatically.
2. npx @n8n/scan-community-package n8n-nodes-PACKAGE is the check the verification guidelines name under "make sure the linter passes." Its README says it "checks npm provenance and runs static analysis," so it runs against the published package. Run it after your first CI release, not just on your local code.

The guidelines add some rules a linter can't fully catch. The code must not read environment variables or read or write files; all data has to come in through node parameters. It should be TypeScript with proper error handling and validation. And the node UI, the docs and every error message must be in English.

No runtime dependencies

This rule stops more nodes than any other. The submission page says verified community nodes "aren't allowed to use any run-time dependencies." The guidelines repeat it under "No external dependencies."

In practice, the dependencies field in package.json has to be empty. Build tooling goes in devDependencies, and n8n-workflow goes in peerDependencies. HTTP calls should use n8n's built-in request helpers (the declarative routing, or this.helpers.httpRequestWithAuthentication), not an SDK or axios.

There's no workaround for a node that needs a runtime dependency to work. In a June 2026 n8n community forum thread, a developer describes an existing node that generates all of its operations at runtime from a bundled OpenAPI spec through a dependency, which makes it unverifiable and unavailable on n8n Cloud. Community members replied that the zero-dependency rule is absolute and that the fix is a clean rebuild. One also suggested checking that a production install leaves node_modules empty. Those replies came from community members, not n8n staff, but they match the documented rule.

Publish with GitHub Actions and npm provenance

Since May 1, 2026, n8n's docs say nodes submitted for verification must be published from GitHub Actions with a provenance statement, and n8n "won't accept verified nodes published directly from a local machine." npm provenance lets anyone check cryptographically which repository, commit and workflow built a package version.

New nodes: the npm create @n8n/node scaffold already includes a publish.yml workflow. Running npm run release locally bumps the version, commits, tags and pushes, and the tag triggers the publish.

Existing nodes: copy the starter's publish workflow to .github/workflows/publish.yml, and upgrade @n8n/node-cli to 0.23.0 or later. Earlier versions don't support the provenance flag the workflow uses.

One-time npm setup: on npmjs.com, open your package settings and go to Publish access → Trusted Publishers → Add a publisher. Choose GitHub Actions, then enter your repository owner, your repository name, and publish.yml as the workflow name (the filename, not the workflow's name:). With trusted publishing there's no long-lived token to store. If you'd rather use a token, store a granular access token as the NPM_TOKEN Actions secret.

The workflow needs id-token: write permission to mint the OIDC token for provenance. The starter workflow already sets this, and it runs on tags that match *.*.*.

Two related source checks appear in the guidelines. The npm repository URL has to match the public GitHub repo and the link has to work, and the author or maintainer has to match between npm and the repository.

Note: the submission page frames GitHub Actions publishing as a requirement for verification. The verification guidelines page and the official starter repo say that from May 1, 2026, all community nodes must be published this way. If you're publishing at all, use the workflow.

Documentation and README

n8n requires "appropriate documentation in the form of a README in the npm package or a related public repository." The guidelines ask for usage instructions, example workflows and the authentication details. A README that will get through review should cover:

• what the service is and what the node does
• installation (the nodes panel for verified nodes, plus manual install for self-hosted)
• how to create the credential: where the API key or OAuth app comes from, and which scopes it needs
• every resource and operation
• one or two example workflows
• compatibility notes and a link to your API docs

The starter repo includes a README_TEMPLATE.md you can start from.

Follow the UX guidelines

The UX guidelines are a stated requirement for verification. The main ones:

• API keys and other secrets are password fields, and an OAuth credential is included whenever the service offers OAuth.
• Each resource offers the standard operations where they make sense: Create, Create or Update (Upsert), Delete, Get, Get Many and Update.
• Use a Resource Locator, defaulting to "From list," when the user has to pick a single item.
• Delete operations return {"deleted": true}.
• If an endpoint returns more than 10 fields, add a Simplify toggle that returns at most 10.
• Labels and the node name use Title Case. Action names, descriptions and hints use Sentence case.
• Use the service's own UI terms, not its API jargon.

Submit through the n8n Creator Portal

Once everything above passes, sign up or log in at the n8n Creator Portal and submit the package. n8n fetches the published version from npm for final vetting, so make sure the version you want reviewed is the latest one on npm and was built by your CI workflow.

n8n "reserves the right to reject nodes that compete with any of n8n's paid features, especially enterprise functionality." If your package name is close to an existing community package, a short note in your submission explaining the difference can help. Community members suggested this in the forum thread above.

What happens after review

n8n's docs don't publish a review timeline, a service-level agreement, or a description of how the portal reports feedback or rejections. Don't plan a launch around a particular approval date. If you're budgeting n8n alongside Zapier or Make, see what each integration costs to build and review.

What is documented is the result. Once a node is verified, any user with verified community nodes enabled can find it from the nodes panel, on self-hosted n8n and n8n Cloud. It shows up under More from the community when they search, and instance owners and admins can install it in one click. Cloud owners can turn verified community nodes off in the Cloud console, and self-hosted admins control the feature with environment variables.

Keep later releases going through the same GitHub Actions workflow, so every version you publish carries provenance.

Common rejection reasons

n8n doesn't publish rejection statistics. These are the documented requirements a node is most likely to miss:

1. A runtime dependency, often an API SDK, axios, or a library that builds operations from an OpenAPI spec at runtime.
2. Published from a local machine, so the version has no provenance.
3. Repo and package don't match: a private repo, a broken repository link, or different authors on npm and GitHub.
4. Lint or scanner failures: no credential test, secrets in plain-text fields, postinstall scripts, or strict mode turned off.
5. Several services in one package, or a proxy for several APIs.
6. A duplicate of an existing node that should have been a pull request.
7. Reading environment variables or files instead of node parameters.
8. A thin README with no auth setup or examples.
9. A license other than MIT, or UI text that isn't in English.
10. Overlap with n8n's paid or enterprise features.

Step-by-step publishing workflow

1. Scaffold the package with npm create @n8n/node. Choose the HTTP API template and your auth type.
2. Name it n8n-nodes-<service> or @<org>/n8n-nodes-<service>, set the MIT license, author, description, homepage and repository.
3. Build the resources and operations following the UX guidelines, and add a credential with a test request.
4. Test locally with npm run dev against a real account.
5. Run npm run lint until it passes with strict mode on, and confirm dependencies is empty.
6. Push to a public GitHub repo under your company's org.
7. On npmjs.com, add the repo's publish.yml as a trusted publisher.
8. Run npm run release to tag and push, and let GitHub Actions publish to npm with provenance.
9. Check that the npm package page shows provenance, then run npx @n8n/scan-community-package <your-package>.
10. Finish the README, then submit at creators.n8n.io/nodes.

If you're generating your node from an OpenAPI spec

Starting from an OpenAPI spec is a sensible way to get full API coverage quickly. What matters for verification is where the generation happens.

• Generate at build time, not at runtime. The output should be plain TypeScript node files, preferably declarative routing, committed to your repo. A node that ships the spec and a parser library and builds operations when n8n loads it has a runtime dependency, and it can't be verified. The forum thread above shows exactly this case.
• Clean up the generated output so it matches the UX guidelines. Raw specs give you operationId-style names, API jargon and huge responses. Rename everything to your product's UI terms, group operations by resource, add Resource Locators and Simplify toggles, and cut endpoints nobody will use in a workflow.
• Add what specs usually leave out: a credential test, OAuth where you support it, a programmatic trigger node if you have webhooks, and pagination for Get Many.
• Publish it the same way as any other node: a public GitHub repo, the publish.yml workflow, provenance, then the scanner.

For more on that approach, see our guide to building an n8n node from an OpenAPI spec.

Get it built and published under your own accounts

NativeShip turns your OpenAPI spec into official, branded integrations for n8n, Make, Zapier and Activepieces. For n8n, the node is checked with n8n's own tooling (lint and security checks) and pushed to your GitHub repo. It's then published to npm with provenance under your accounts, so the package is yours. Our team builds and tests it and submits it for review. Approval is always n8n's decision, so we can't guarantee it.

Plans start at a one-time $149 (Developer) or $349 (Startup). See pricing, browse the nodes we've shipped, or start at nativeship.io.