The 5 checks that tell you if a workflow JSON will actually import
The most common reason a template fails is not a bug in the template: it is that nobody ran it before
selling it. Here is the exact checklist we use — with the numbers from our own end-to-end test on two
clean n8n versions — so you can vet any .json in ten minutes, before you pay for it or
before you blame yourself for a broken import.
Check 1 — Do the node types exist in your instance?
A workflow JSON is a list of nodes, each with a type like n8n-nodes-base.httpRequest
or n8n-nodes-base.removeDuplicates. If your instance does not know a type, the node imports as an
unknown block and the chain dies there. The catalog is queryable:
GET {N8N_URL}/types/nodes.json # one entry per node name per version groupThe trap: that file lists several entries per node name, and the last one is usually the oldest. A script that keeps the last entry reports versions that do not exist and "unknown" nodes that are perfectly fine. Take the maximum of all entries for each name. On our own test instance (n8n 2.43.6, 559 installed types) the two workflow files resolved 28/28 nodes · 0 unknown types.
Check 2 — Does every typeVersion fit your n8n?
Each node also declares typeVersion. Compare it against the maximum your instance offers. What
matters is knowing what happens when it is higher, because the honest answer is not "it breaks":
We tested at the exact edge of a compatibility promise — "n8n 1.60 or newer" — in a clean
n8n 1.60.0 container. Three nodes declared a version above that release's maximum:
removeDuplicates v2 (max 1.1), readWriteFile v1.1 (max 1) and
respondToWebhook v1.4 (max 1.1). n8n resolved them with the newest version it had and
all of them executed correctly: 0 missing types, 13/13 nodes green. So a version above the
maximum is a warning, not a verdict — but it is exactly the case you must have tested before
claiming support. If a seller says "works on 1.60+", ask for the run in 1.60.
Check 3 — Is there pinned data in the file?
pinData is a companion feature: it freezes node output so a flow can be demonstrated without
calling any API. In a file you are evaluating, pinned data is dangerous in a specific way: the workflow
appears to work and produces beautiful results while talking to nothing. Open the JSON and
search for pinData. If it is there, delete it and run again — the second run is the real test.
Check 4 — Are credentials placeholders, and is anything hardcoded?
Two failures in opposite directions. A node that carries a credentials block with an
id from the author's instance imports cleanly and fails at execution with "credentials not found".
A node with an API key typed into a header or a URL is worse: it leaks on import and it is invisible until you
read every field. Grep the file for credentials, apiKey, Bearer,
sk- and AIza. Our own release pipeline fails the build if any node contains a
hardcoded key — that assertion is one of the tests shipped inside the kit.
Check 5 — How many nodes are executable, and how many are buttons?
"14 nodes" and "13 nodes" can describe the same file. Sticky notes (the yellow annotation blocks) are nodes in the JSON: they count in the file, they do nothing at runtime. Our lead-finder flow is 14 nodes total, 13 executable + 1 sticky note. Ask for the executable number, then verify it in the file. It is a two-line check and it tells you whether the seller counted or copied.
Bonus — the stateful node that makes a good flow look broken
If the workflow uses RemoveDuplicates in "entries" mode, the seen keys are stored per
workflowId in the instance database (table processed_data). Run it once: 3 items.
Run it again with the same input: 0 items, no error, chain stops. Deterministic zero on the second run is not
a bug — it is memory. Before judging a flow, either run it in a disposable instance or clear the
deduplication history. We wrote the whole post-mortem separately, because it cost us a day.
The 10-minute protocol
1. grep -c '"type"' file.json # node count (executable + notes)
2. grep 'pinData' file.json # empty output = good
3. grep -E '(apiKey|Bearer|sk-|AIza)' file.json # empty output = good
4. max version per type from /types/nodes.json # 0 unknown = good
5. docker run --rm n8nio/n8n:latest # import + execute
n8n import:workflow --input=file.json
n8n execute --id=<id> --rawOutput # look at lastNodeExecuted
Two notes from doing this for real: in n8n 1.60 the CLI expects --input to be an
array of workflows (workflows.map is not a function if you pass a bare object),
and n8n execute does not accept --file — import first, then execute by
--id. Also keep the disposable container: running n8n execute inside a container that
is already serving fails with Task Broker's port 5679 is already in use.
What a passing run looks like
Not "it imported". A real pass is: every node in success, lastNodeExecuted equal to
the node you expect, and an output artefact with the right number of rows. In our case: 13/13 nodes green,
lastNodeExecuted: 11 - Enviar a tu webhook/CRM, and a 1,529-byte CSV with
4 qualified rows out of 11 businesses. External services were replaced with local mocks — the logic nodes ran
verbatim, which is where the real risk lives.
This checklist is not marketing copy: it is the test suite that ships inside the kit. The Pro package includes
TESTING.md with the full evidence — every version, every node, every number.
See what's inside →