n8n Node Catalog & Community Package Scraper

Get every n8n node in one structured dataset — the nodes built into n8n, the community nodes n8n has officially verified, and every community node package published to npm under the n8n-community-node-package keyword.

For each node you get the runtime node type, type versions, resources and operations, and credential requirements, plus a full set of trust and maintenance signals: npm provenance, license, repository, weekly downloads, publish recency, and whether the package still looks maintained.

What does the n8n Node Catalog scraper do?

Most n8n scrapers target the template library, and the ones that cover nodes read n8n's public directory listing. This Actor indexes the node ecosystem itself, from npm — it reads each package's packument and published tarball, so it recovers the things a directory page never shows: exact runtime node types, type versions, resources and operations, credential requirements, npm provenance, and maintenance signals. That is the data you actually need to validate a workflow, generate one, or decide whether an n8n community node is safe to depend on.

• 🧩 Every n8n node type in one place — 527 built-in nodes (~570 including hidden ones), ~1,490 verified community nodes, and ~13,500 community packages on npm, including ones that never carried n8n's keyword.
• 🔢 Exact node types and typeVersions — the strings you actually paste into workflow JSON, not display names.
• 🔐 Credential requirements per node — recovered by parsing the published package, because neither n8n API ever returns them.
• ✅ npm provenance and verification status — n8n has required npm provenance for node verification since 1 May 2026.
• 📉 Maintenance risk scoring — active, stale, or abandoned, based on the real npm publish date.
• ⚡ Targeted lookup mode — check a handful of specific n8n community nodes in seconds instead of crawling the whole ecosystem.
• 🔁 Resumable runs — state is checkpointed, so an aborted or migrated run continues instead of restarting.

Because it runs on Apify, you also get scheduled refreshes, API access to the results, exports to JSON/CSV/Excel, and integrations with everything else in your stack — including n8n itself.

What data can you extract from the n8n ecosystem?

Field	What you get
nodeType	The runtime type string you put in a workflow, e.g. n8n-nodes-base.httpRequest
displayName	The node's human-readable name as shown in the n8n editor
packageName	The npm package the node ships in
typeVersions	Known type versions, e.g. [1, 1.1, 2]
operations	Resource/operation pairs the node exposes, with actions and descriptions
credentialTypes	Credential types the node requires, e.g. ["apifyApi"]
group, categories	Node grouping (trigger, transform, …) and n8n's own categories
isTrigger, isAiTool	Whether the node is a trigger, and whether it can be used as an AI Agent tool
isVerified	Whether n8n has verified the package
hasProvenance	Whether the npm release carries a provenance attestation — required for n8n verification since 1 May 2026
maintenanceRisk	active (<90 days since publish), stale (90–365), abandoned (>365), or unknown
npmWeeklyDownloads	Weekly npm download count
githubStars	Repository stars (needs an optional GitHub token)
license, repoUrl, docsUrl	License, source repository, and the n8n documentation page
lastPublish	Real npm publish date of the latest version
nodeTypeConfidence	exact when declared by n8n or read from the compiled node; inferred when derived by naming convention
detailLevel	full (n8n's API), enriched (parsed from the tarball), or packument (npm metadata only)

The per-package dataset adds keywords, maintainers, riskFlags (noRepo, noLicense, noProvenance, deprecated, unpublished), firstPublish, versionCount, unpackedSize, and discoveredVia.

Why scrape the n8n node ecosystem?

• Validate workflows before they break. Check that every type and typeVersion in a workflow JSON actually exists, and catch nodes running on stale versions.
• Ground an AI workflow generator. Most n8n workflow generators hallucinate node types because they have no registry to check against. This is that registry.
• Vet an n8n community node before you install it. A package without npm provenance cannot be verified by n8n as things stand — this catalog tells you which ones those are, alongside license and maintenance risk.
• Audit your n8n instance. Cross-reference the community nodes you have installed against maintenance risk, license, and verification status.
• Research the ecosystem. Which n8n integrations exist? Which are abandoned? Where is the gap worth building into?
• Feed an AI agent. A clean, filterable list of every n8n node and its operations is exactly the grounding an agent needs to reason about n8n.

How to use the n8n node scraper

1. Click Try for free at the top of this page.
2. Leave the defaults for every built-in node in under ten seconds, or add Verified community nodes and All npm community packages under Sources for wider coverage.
3. To check specific packages instead, put their npm names in Package names — see Look up specific n8n community nodes.
4. Click Start.
5. When the run finishes, open the Output tab. It links both datasets: per-node rows in the default one, per-package rows in packages.
6. Download as JSON, CSV, or Excel, or pull the data straight from the Apify API.

To keep your index fresh, add a Schedule — the n8n ecosystem gains packages daily.

Input

Everything is optional. The defaults catalog the built-in nodes only — 527 node rows in under ten seconds. That is deliberately the fast path. Add verified for n8n's reviewed community catalog (2,013 nodes in around fifteen seconds), or community to bring npm into the run, which turns seconds into minutes. The Input tab groups the fields into four sections.

What to catalog

Field	Type	Default	What it does
sources	array	["builtin"]	builtin, verified, community
packageNames	array	[]	Catalog only these npm packages. Empty means the selected sources
includeHidden	boolean	false	Include the ~45 built-in nodes n8n marks hidden

Add community only when you need the npm long tail. It is the only source that brings npm into the run, and the only reason a run takes longer than a few seconds.

Coverage and limits

Field	Type	Default	What it does
coverage	string	full	How far past npm's ~5,000-result ceiling to push — see below
maxPackages	integer	0	At most this many packages in total, across every source (0 = unlimited). Spent in source order

coverage sets how much of the long tail the community source reaches:

Level	Registry name scan	Keyword partitions	Use it when
full	yes	up to 25	You want every n8n package on npm (default)
balanced	no	up to 100	You want most of the tail, from search alone
searchWindow	no	none	The first ~5,000 packages are enough — fastest

full is the complete option and also a fast one: the registry scan reads npm's whole package list in under a minute, where reaching the same packages through search alone takes far longer and gets rate-limited on the way. See Tips for how the two techniques differ.

Detail level

Field	Type	Default	What it does
enrichment	string	none	none, popular (100+ weekly downloads), or all

Enrichment parses npm tarballs to recover exact node types, display names, type versions, and credentials. It is slower and heavier, so it is off by default; popular keeps a full run proportional to what people actually use.

Access and network

Both are optional, and both only matter for long runs over the community source.

Field	Type	Default	What it does
githubToken	secret string	—	Enables star counts and last-commit dates for unverified packages
proxyConfiguration	object	Apify Proxy	On by default. npm rate-limits per IP, and spreading a run across several egress IPs is what keeps a full run in minutes

Input example

{
    "sources": ["builtin", "verified", "community"],
    "coverage": "full",
    "enrichment": "popular"
}

Look up specific n8n community nodes

If you already know which n8n community nodes you care about — the ones a workflow depends on, or a package you are about to install — name them in packageNames instead of crawling the ecosystem:

{
    "packageNames": ["@apify/n8n-nodes-apify", "n8n-nodes-evolution-api"]
}

This switches the Actor into lookup mode:

• npm discovery is skipped entirely, and the built-in and verified sources are narrowed to the names you gave;
• every package is enriched from its tarball, so you get exact node types, type versions, and credential types rather than inferred ones;
• a name npm has never heard of is reported as a warning, so a typo is visible rather than silently missing;
• a package that exists on npm but ships no nodes — n8n-core is n8n's execution engine, not a node package — gets a row in the packages dataset and none in the nodes dataset, and is named in a warning and in requestedWithoutNodes in the run summary. So a two-package lookup can legitimately return two package rows and one node row.

Two packages resolve in under ten seconds, against minutes for a full catalog. Anything npm knows about works, whether or not n8n has verified it.

Output example

Two datasets, both linked from the run's Output tab. The default one holds one row per n8n node — the lookup table. The packages dataset holds one row per package — for ecosystem research. Join them on packageName.

{
    "nodeType": "@apify/n8n-nodes-apify.apify",
    "nodeTypeConfidence": "exact",
    "displayName": "Apify",
    "packageName": "@apify/n8n-nodes-apify",
    "packageVersion": "0.7.0",
    "origin": "verified",
    "detailLevel": "enriched",
    "typeVersions": [1],
    "group": ["transform"],
    "categories": ["Development"],
    "operations": [
        { "resource": "actor", "operation": "run", "action": "Run an Actor", "description": "Run an Actor" }
    ],
    "credentialTypes": ["apifyApi"],
    "isTrigger": false,
    "isVerified": true,
    "hasProvenance": true,
    "license": "MIT",
    "repoUrl": "https://github.com/apify/n8n-nodes-apify",
    "npmWeeklyDownloads": 46656,
    "maintenanceRisk": "active",
    "lastPublish": "2026-07-14T09:12:03.000Z"
}

You can download the dataset as JSON, CSV, Excel, HTML, or XML, or fetch it through the API.

A note on detailLevel

n8n's API returns full operation data for built-in and verified nodes, but neither endpoint ever returns credential requirements (measured: zero of the verified records carry them), and npm metadata alone cannot supply display names, type versions, or operations. So each row states how much is actually known about it.

Set enrichment to popular or all to upgrade unverified packages from packument to enriched, which recovers exact node types, display names, type versions, and credential types. Enrichment also runs against verified packages, where it fills in only the credentials n8n omits and leaves that package's authoritative operations and node types untouched — so those rows stay full. Lookup mode enriches everything it touches by default.

How fast is the n8n node scraper?

The Actor talks to JSON APIs rather than rendering pages, so it is light to run.

Run	Roughly what it covers	Node rows	Time
Defaults (sources: ["builtin"])	All 527 built-in nodes	527	~5 seconds
packageNames lookup, two packages	Exactly those packages, fully enriched	a handful	Under 10 seconds
builtin + verified	2,013 fully-detailed nodes over 1,182 packages	2,013	~17 seconds
builtin + verified + community, "searchWindow"	~5,000 npm packages, plus the core above	~10,700	~1 minute
community alone, coverage: "balanced"	Most of the npm long tail, community only	~15,900	~2.5 minutes
builtin + verified + community, "full"	Every n8n package on npm, ~13,500, plus the core	~24,800	~6.5 minutes
Same, plus enrichment: "all"	The same, every package also parsed from its tarball	~24,700	~7 minutes

Going for the entire catalogue? Use a residential proxy. The community rows above were measured with proxyConfiguration set to Apify's residential group:

{ "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] } }

Deselect the community source for the high-quality core, use coverage: "searchWindow" when you don't need the long tail, and leave enrichment at none unless you specifically need credentials and operations for unverified packages.

How much does it cost to scrape n8n nodes?

This Actor is billed pay per event: $6 per 1,000 node rows, which is $0.006 a row. You are charged for the rows a run actually writes. Only the nodes dataset is metered — the per-package rows come with it.

That is the standard rate, and the most you will pay. Apify Store discounts apply automatically — accounts on higher Apify plans are charged a lower rate per row, for the same input and the same output.

enrichment changes how much is known about each row, not how many rows there are, so it adds detail at no extra cost. To cap the bill, narrow sources, drop coverage to searchWindow, or set maxPackages.

Integrations and API access

• Use it from n8n. Apify's official n8n integration lets an n8n workflow run this Actor and read its dataset directly — so n8n can query its own node ecosystem.
• Call it from the API. Start runs and fetch results with the Apify API, or the JavaScript and Python clients.
• Schedule it. Add a schedule to keep a fresh mirror of the n8n node ecosystem.
• Pipe it anywhere. Webhooks, Zapier, Make, Slack, Google Sheets, and the rest of the Apify integrations.

Run it and get the rows back in a single call — this returns all 527 built-in node records as JSON:

curl -X POST "https://api.apify.com/v2/acts/mediocre_interest~n8n-node-catalog/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"sources":["builtin"]}'

Swap the body for {"packageNames":["@apify/n8n-nodes-apify"]} to look up a single package, or {"sources":["builtin","verified"]} for the full 2,013-node core. That endpoint returns the default dataset — the per-node rows. The per-package rows live in the separate packages dataset, linked from the run's Output tab.

Tips and advanced options

• Runs resume. Discovered packages are checkpointed to the key-value store under state-, so an aborted or migrated run picks up where it left off. The registry scan is repeated on resume rather than checkpointed.
• Pick coverage by how much of the long tail you need. full scans every name in the npm registry and adds up to 25 keyword partitions; balanced skips the scan and uses up to 100 partitions; searchWindow stops at npm's ~5,000-result ceiling. discoveredVia on each package row records which pass found it — registry, search, or keyword:<term>.
• Read the run summary. Each run writes summary-run to the key-value store: row counts, coveragePct against npm's reported total, stages with the wall clock broken down by phase, failedSources, and requestedWithoutNodes.
• maxPackages is a total budget, not an npm-only one. It counts every package the run writes, whatever source found it, and is spent in source order — built-in, then verified, then npm. Set "sources": ["community"] to spend a small budget on npm packages instead. The run logs a warning when the budget runs out before npm discovery starts.
• Lookup mode ignores sources and enrichment. Naming packages in packageNames searches all three sources for those names and enriches every one from its tarball.
• Add a githubToken for star counts and last-commit dates on unverified packages. Without one GitHub allows 60 requests an hour and that step is skipped.
• Use the RESIDENTIAL proxy group for a full community run: { "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] } }.
• Join the two datasets on packageName for per-node detail alongside full package metadata.
• Filter to what you trust with isVerified, hasProvenance, and maintenanceRisk before feeding the catalog to an agent.
• Set includeHidden to add the ~45 built-in nodes n8n marks internal or deprecated.

What other Actors work with this one?

Actor	What it does
Multi-Platform Job Scraper	Collects job listings across several boards into one dataset
Ad Library Scraper	Pulls ad creatives and spend data from the Google, Meta and LinkedIn ad transparency libraries
n8n Workflow Auditor	Lints n8n workflow JSON for hardcoded credentials, unauthenticated webhooks, deprecated nodes and missing error handling

FAQ

Where does the n8n node data come from?

n8n's public node APIs at api.n8n.io, the public npm registry, and optionally the GitHub REST API. All are public, documented-or-observable endpoints, queried at modest concurrency.

How many n8n nodes are there?

527 built-in nodes ship with n8n — around 570 if you count the hidden internal and deprecated ones — and n8n has verified roughly 1,490 community nodes across ~1,175 packages. Beyond that, npm reports around 12,500 packages tagged n8n-community-node-package — and a full run finds roughly 13,500, because it enumerates the registry by name rather than by keyword and so also catches packages whose authors never tagged them.

Is nodeTypeConfidence: inferred reliable?

n8n node types follow the convention <packageName>.<camelCase node name>, and spot-checks against packages where the true name is known show the convention holding. It is still convention rather than fact, which is why it is labelled — enable tarball enrichment to resolve those rows to exact.

Why is maintenanceRisk sometimes unknown?

n8n's verified-node API reports its own catalog sync timestamp rather than the npm publish date, so it is deliberately not used to score maintenance. A run that includes the community source fills in the real date from npm.

Can I use this to check my own n8n instance?

Yes. List the community node packages installed on your instance in packageNames and the Actor returns their node types, credentials, verification status, license, and maintenance risk in seconds.

Support and custom solutions

Found a bug, or need a field that isn't here? Open an issue on the Issues tab of this Actor. Custom versions of this Actor are available on request.