Npm n8n integrationAutomate Npm with n8n.
The Npm n8n integration puts the registry inside a workflow. The node ships 5 operations across 2 resources, packages on one side and distribution tags on the other, and reads whichever registry the credential points at. There is no npm trigger, so a schedule or another app starts the run.
Verified Trustpilot reviews · AI, automation & growth agency
What does the Npm n8n integration actually do?
The npm node calls the npm registry API from inside n8n. It reads what a package declares: the metadata of one exact version, the full list of published versions, the distribution tags that point a name at a version, and the results of a keyword search. One operation writes, the one that moves a distribution tag to another version. Everything runs against the registry set in the credential, the public one or your own.
A dependency watch is the first shape teams build. A Schedule Trigger fires each morning, the node returns the published versions of every package the product depends on, and a comparison against the rows already stored in Google Sheets isolates the ones that moved. What people actually read is the Slack message at the end, one line per package that gained a release.
The second shape runs at release time. A build server calls an n8n Webhook with the package name and the version it just published, the node pulls the metadata of that exact version, and the workflow files the record in Postgres next to the build that produced it. Nobody has to open the registry in a browser to know what shipped.
The third shape is a promotion step. Once a candidate passes review, the workflow moves the distribution tag that teams install from onto the version that was approved. Package search covers a smaller need, a keyword sweep of the registry when nobody knows yet what exists for a given job.
The node stops at those 5 operations. Publishing a package, removing one, deprecating a version, changing owners: none of that is here. The HTTP Request node calls the rest of the registry API and reuses the same npm credential, so a missing endpoint costs one extra node rather than a change of tool. Two details are worth knowing before you build. Get Package Metadata wants an exact version, which usually means listing versions first and feeding the one you picked into the second call. And package search walks its results with Limit and Offset, one call per page, with no option to sweep everything at once.
The hosting question comes next. The node ships with n8n, on n8n Cloud and on a self-hosted instance, with nothing to install and no extra cost on the n8n side. The n8n review goes through where the tool is comfortable and where it is not.
How do you connect npm to n8n?
- 01
Create the access token on npm
Sign in to the npm account that owns the packages you care about, open the profile menu and pick Access Tokens. Generate one there and copy the value. That string is what n8n sends on every call, so it deserves the same care as a password: whoever holds it talks to the registry with the same rights as the account behind it.
- 02
Save it as an n8n credential
In n8n, open Credentials and create an npm credential. Paste the token into Access Token, then look at Registry URL: keep the public registry value it comes with, or replace it with the address of your own registry. A credential is created once and reused everywhere, so from that point the npm node offers it in a dropdown and you never retype the token.
- 03
Wire the node and run it once
Drop the npm node into a workflow, select the credential, then choose the resource, Package or Distribution Tag, and the operation under it. Fill the required fields by hand for the first attempt and execute that node on its own. What comes back in the output panel is exactly what the following nodes will map, so it pays to look at it before building the rest of the branch.
The 5 operations of the npm node, one by one
The Npm node exposes 5 operations across 2 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.
| Resource | Update | Get All | Get Metadata | Get Versions | Search |
|---|---|---|---|---|---|
| Package | ✓ | ✓ | ✓ | ||
| Distribution Tag | ✓ | ✓ |
Package
3 operationsReturns all the metadata for a package at a specific version
package.getMetadataWhat you see in n8n
Notes & use cases
Ask the registry about one precise release and get back everything that version declares, as a single item. It reads without changing anything, so it can be replayed as often as an investigation needs.
Key parameters
- Package Name: the package name as published on the registry, typed in or mapped from an earlier node with
{{ $json.field }}. - Package Version: the exact version string. The field is required, the node stops when it is empty, and there is no shortcut to the newest release here.
Returns all the versions for a package
package.getVersionsWhat you see in n8n
Notes & use cases
One package name goes in, the list of versions published for it comes out. This is the operation that answers the question of whether anything landed since yesterday, because nothing tells n8n about a publication on its own.
Key parameters
- Package Name: the package to read, static in the field or taken from the incoming item, for instance
{{ $json.field }}.
Search for packages
package.searchWhat you see in n8n
Notes & use cases
Runs a keyword search against the registry and returns the packages that match, in the order the registry ranks them. Useful when nobody on the team knows yet what exists around a subject.
Key parameters
- Query: the query text used to search for packages, a single keyword or a few words.
- Limit: the maximum number of results the node returns for that call.
- Offset: the rank the result list starts at, so a second call continues after the first batch.
Distribution Tag
2 operationsReturns all the dist-tags for a package
distTag.getManyWhat you see in n8n
Notes & use cases
Returns the distribution tags of a package. A dist-tag is a name pointing at one published version, which gives a stable label where people would otherwise have to remember a version number.
Key parameters
- Package Name: the package whose labels you want to read.
Update a the dist-tags for a package
distTag.updateWhat you see in n8n
Notes & use cases
Here the node writes: it points a label at the version you name. This is the only operation of the node that changes something in the registry, so its place is at the end of a workflow, after the check that approves the version.
Key parameters
- Package Name: the package the label belongs to.
- Package Version: the version the label targets after the call, often carried over from the previous node with
{{ $json.field }}. - Distribution Tag Name: the name of the label the call points at the version above.
Need help automating Npm with n8n?
A person reads every message.
