What to Test Before Publishing a Generated n8n Node

A generated n8n node needs more evidence than a successful build. Check the package that users will install, load it in n8n, run an authenticated request, and inspect both a useful result and an expected failure. Each check answers a different question. A passing linter cannot show that the node sent a request to the right API.

The published TidyCal community-node package, version 1.0.1, is a useful example. I inspected its npm tarball on 20 October 2026. That inspection found problems before a live workflow test: its README says credentials are unnecessary, the node declares no n8n credential, and generated destination fields default to https://api.example.com. TidyCal's API documentation says requests need authentication. I have no authenticated n8n execution for this package, so I would stop at this finding rather than describe the node as working.

Inspect the package customers will receive

Start with the exact release, not a screenshot of the editor or a newer source checkout. Record the package name and version, then inspect the files inside the npm tarball. Two npm commands do most of this without installing anything:

# What a release candidate will ship, from the project folder
npm pack --dry-run

# What a published version contains and declares
npm view @scope/n8n-nodes-example@1.0.1 dist.tarball dependencies repository n8n

npm pack --dry-run lists every file that would go into the tarball, so you can spot a missing dist folder or an accidental .env. npm view shows the declared runtime dependencies (n8n's verification rules allow none), the repository URL (which must match the GitHub repository), and the n8n block that tells n8n which node and credential files to load. Compare them with the repository and the release notes. A later commit on the main branch does not repair an older package already published to npm.

For TidyCal 1.0.1, the package metadata points n8n to dist/nodes/Tidycal/Tidycal.node.js. The package includes the compiled node, a README, and license metadata. Those files answer the first question: what was shipped? They do not answer whether its requests can reach TidyCal.

The next inspection is where this release fails. The README's “does not require credentials” sentence conflicts with TidyCal's authenticated API. The compiled node has an empty credentials declaration. Its default destination is a placeholder, and its generated server URL needs repair. If the setup instructions and compiled node disagree with the API's authentication and host, pause the release review. Fix the package, publish a corrected version, and inspect that new tarball.

The NativeShip credentials guide explains the credential structures a node may need. For a particular API, the credential type, required permissions, and request header must still be checked against that API's current documentation.

Separate the checks by what they prove

Build and lint checks answer a different question from running the node in n8n. I would record the result of each layer separately:

Check	What a pass would establish	What it would leave open
Package inspection	The intended files, metadata, credential declaration, and documentation are present in the release.	Whether the node loads or makes a valid request.
Build and lint	The matching source compiles and passes the configured static rules.	Whether the API accepts its credentials, URL, and parameters.
Local n8n load	The node appears in the editor and its resource, action, and field choices are usable.	Whether a real operation succeeds.
Authenticated read	A safe operation reaches the intended API and returns inspectable data.	Whether write actions and failures behave correctly.
Controlled write and expected error	The selected action changes only the intended test data and exposes a useful failure when the API rejects a request.	Whether every operation and environment is covered.

Keep the source checkout, npm package, and test result tied to the same version. If you fix code after a failed test, rerun the affected checks on the package you plan to ship.

Run n8n's scanner and verification checks

Before loading the node, run the static scanner n8n uses during verification against the published package:

npx @n8n/scan-community-package @scope/n8n-nodes-example

Then check the release against the rest of the verified community node checklist: built with the n8n-node tool, one service per package, public MIT-licensed repository, matching npm and GitHub author, no runtime dependencies, no environment-variable or file-system access, English-only text, and a GitHub Actions publish with provenance. These checks matter even if you do not plan to submit yet. From n8n 3.0, self-hosted instances block unverified community nodes by default, so a package that cannot pass review reaches far fewer users.

Run the source checks, then open the node

In a checkout that matches the release candidate, install dependencies with the project's lockfile, build, and lint. The TidyCal package declares build, lint, and dev scripts. Commands such as these belong in the test record with their exit codes and tool versions:

npm ci
npm run build
npm run lint
npm run dev

These are the intended checks, not commands I have run successfully for TidyCal 1.0.1. n8n's local-node testing instructions say npm run dev can build the node, start a local n8n instance, and reload changes. From n8n 3.0, n8n-node dev runs that instance in a container, so Docker or Podman must be installed. To test against an instance you already run, use n8n-node dev --external-n8n and start n8n with N8N_DEV_RELOAD=true. You can pin the n8n version you want to test against with --n8n-image. If the node does not appear in the editor, the node not showing guide lists the usual causes. In that instance, search for the node by its displayed name, add it to a workflow, and inspect the fields the user will actually see.

Check the form against the API. Does the user know where to obtain a booking type ID? Is a single booking's start time treated as required? Does the credential setup match the account's permissions, and does saving the credential run a credential test? A form can load cleanly while still asking the user for the wrong values. The NativeShip OpenAPI-to-n8n guide shows where generated resources and operations can be reviewed before building a package.

Require a request and a useful failure

For the corrected TidyCal package, a low-risk first request would list booking types using a test account permitted to use the API. Inspect the actual destination, authentication, response status, and returned JSON. Do not infer success from a green editor preview. Redact account IDs and tokens before sharing evidence.

Then test one controlled write, such as a booking made against a booking type reserved for tests. Record the input, the returned booking ID, and how you confirmed the booking exists. Finally, try an expected failure, such as an unavailable slot or a credential without the necessary permission. The node should show a useful error and must not imply that the booking succeeded.

For each run, capture the n8n version, package version, action, redacted input, expected result, actual response, and whether it passed. A screenshot can help explain the result, but the response and the effect in the service are the evidence. Do not publish a screenshot with a token, customer name, or private booking detail.

The TidyCal 1.0.1 review has not reached this stage. No authenticated read, controlled write, or expected-error execution is recorded here. The package inspection already found reasons to repair and retest before making a working-node claim.

Keep a test record per release

A short record makes the next release and the next support ticket much easier. One row per check is enough:

Field	Example entry
Package and version	@scope/n8n-nodes-example@1.1.0
n8n version and deployment	3.0.x, self-hosted Docker
Check	Authenticated read: Booking Type > List
Redacted input	Test account, page 1
Expected result	2xx with a list of IDs
Actual result	Pass: 3 items returned
Evidence	Execution ID, redacted response saved in the release folder

Store the record next to the release notes, not in a chat thread, so a later maintainer can compare it with a failing run.

Publish the version that passed

When the corrected release has passed the relevant checks, review the final npm tarball once more. Make sure the README describes the same credential setup, installation limits, operations, and version you tested. Keep the redacted execution record so a later API change or customer report can be compared with the release that originally worked.

Publishing with npm provenance gives a release a verifiable link to its source and build; the NativeShip publishing guide covers that step. Provenance does not replace the API run. If you are starting a NativeShip project, plan the test account and one read and one write operation before generating the package. You will know what the finished node has to prove.