An n8n Node Launch Checklist for SaaS Teams

An npm release gives customers a package to install. A customer launch gives them a reason to install it, a way to connect their account, and a workflow they can finish. Before announcing the integration, confirm who can install this version, test one useful workflow, publish setup instructions, and decide who will handle problems and updates.

This article starts after the build decision. If you are still deciding whether your product needs a node, use the SaaS n8n integration decision guide. Once a package exists, the work shifts to getting a real customer from “I found the node” to a successful first execution.

State exactly what is available

“Our n8n integration is live” can mean several different things. A public npm package can be installed on an eligible self-hosted n8n instance. It does not automatically appear in the n8n node picker for Cloud customers. n8n's community-node installation documentation says npm installation of unverified community nodes is for self-hosted instances; verified nodes can be installed from the nodes panel where that feature is enabled.

n8n 3.0 narrows the unverified route further. It sets N8N_UNVERIFIED_PACKAGES_ENABLED to false by default, so an unverified package will not install on an upgraded self-hosted instance until an admin turns the setting back on, and unverified packages that were already installed stop loading. If your node is not verified yet, say so plainly and include that admin step in your instructions. The n8n community node verification guide explains what the review needs, so you can plan the launch around it.

Related: n8n 3.0 turns off unverified community nodes, covering who it affects and why to submit before stable 3.x ships.

Use a status line customers can act on:

Current state	What to tell customers	Link them to
Package published, not yet verified by n8n	“Available as a community node for self-hosted n8n. On n8n 3.0 and later, an admin must allow unverified community nodes first.”	Exact npm package, self-hosted installation instructions, and the N8N_UNVERIFIED_PACKAGES_ENABLED setting.
Submitted for verification	“Submitted for n8n review; self-hosted installation is available.”	The same installation path and a dated status update.
Verified and visible in the node picker	“Find and install it from the n8n nodes panel, if verified community nodes are enabled for your instance.”	The node listing and picker instructions.

Only use the row that matches the current release. A provenance statement, npm publication, Creator Portal submission, and n8n verification are separate facts. The NativeShip provenance guide explains the publishing side. n8n's submission documentation covers the separate verification requirements and review path. Do not advertise Cloud installation while verification is pending.

Put the first successful workflow ahead of the announcement

A package page can list twenty actions and still leave a new user unsure where to start. Pick one customer job that uses the node's most useful action. Test it with the released package version in an n8n instance that matches the installation instructions you plan to publish.

The example should let someone follow the whole path:

1. Start with a real trigger. Show what begins the workflow, such as a schedule, webhook, or event that the product actually supports. Do not imply the node includes a trigger if it only provides actions.
2. Connect the product account. Name the required credential, permissions, and any paid-plan requirement. Show where the customer obtains the credential without exposing a real token in screenshots or shared workflow JSON.
3. Run one action with representative input. Show the fields that matter and where IDs come from. A worked input beats a screenshot of an empty node form.
4. Use the result. Pass a real output field to a following step. Show what the workflow should do if the API rejects the request or returns no records.
5. Repeat from the published package. Record the package version and n8n environment used for the example. A workflow tested against a local development build may behave differently from the version customers install.

If you do not have a tested workflow yet, call it an example you are preparing. Do not publish an importable template with made-up output and describe it as ready to run.

Give customers one clear setup page

Your launch page should make installation and first use possible without a support conversation. At minimum, include the exact package name and version, current installation eligibility, supported n8n environment, credential setup, the first tested action, a small workflow example, and a support route. Link the package to its public source repository and changelog so customers can inspect what they are installing and what changed.

Keep the first screen of that page practical. A customer deciding whether to try the node needs answers in this order:

Question	What your page should show
Can I install it in my n8n instance?	Current verified or unverified status and the right installation path.
Can I connect my account?	Credential type, required permissions, and any account or plan limit.
Will it do my task?	Supported resources and actions, plus one tested workflow.
What if it fails?	A troubleshooting section and a contact or issue-report route.
Who maintains it?	Package owner, repository, version history, and a way to report API changes.

The n8n community node README checklist has a template for the package side. Check the npm README and your own integration page against each other. A new version, renamed action, or changed credential flow should not leave one page describing the old release.

Announce the use case and the installation limit together

Lead with the job the integration helps a customer do. “Create a contact in our product from an n8n workflow” tells someone more than “We launched on n8n.” Follow it with the installation status in the same announcement.

Start with people who already asked for the integration or use the relevant API. Put the setup page in your product's integration directory, developer docs, and release notes. If your app has an integrations screen, link from there to the same instructions. One clear destination is easier to maintain than several launch posts with slightly different setup steps.

For a package that is published but awaiting n8n verification, the announcement can say: “Our n8n community node is available for eligible self-hosted instances. It supports [the tested task]. Use [the setup page] to install it and run the example workflow. We will update this page if its n8n verification status changes.” Replace the bracketed details with facts from your release. Do not turn submission into an approval claim.

Treat support and updates as part of the release

The first customer questions usually tell you where the setup path is weak: a missing permission, an unclear ID field, an API error with no useful message, or an n8n version the team never tested. Assign a person or team to receive these reports and decide when to fix the node, the documentation, or the API.

For each report, collect the package version, n8n version and deployment type, action name, redacted error, and expected result. Never ask customers to post API tokens or private workflow data in a public issue. Keep release notes that name the changed actions and any upgrade risk; the API change maintenance guide covers the release process. n8n warns that a breaking community-node update can affect workflows using that node, so test changes against the example workflow before telling customers to upgrade.

This is also where source ownership matters. Know who can publish the npm package, merge repository changes, and answer support requests. If the person who launched the node leaves, customers still need a path to a fix.

Measure progress beyond npm downloads

An npm download is evidence that the package was fetched. It does not tell you whether a customer connected an account, ran an action, or kept a workflow active. Use separate measures for each step:

Signal	What it can tell you	What it cannot prove
Integration-page visits	People reached the instructions.	They installed the node.
Setup-page or package-link clicks	People showed intent to try it.	The install succeeded.
npm downloads	The package was fetched.	A real customer ran a workflow.
Support tickets and opt-in feedback	Where the setup or node failed.	The total number of active users.
Confirmed customer examples	A named workflow worked in its stated environment.	Every action works for every account.

If you can observe successful connections or executions through your own product with appropriate consent, record those separately. Review the first questions and failures before adding more actions. A fix that helps someone complete the first workflow can be more valuable than a larger node menu.

NativeShip can help a SaaS team start from its API and create an n8n node project. Plan the customer setup page, tested workflow, and support owner alongside the package so the first announcement describes something customers can use.