Publishing community templates to the n8n library: what the review actually asks for

#automation #opensource #tutorial

The n8n template library is one of the few places where a self-hosted automation builder can publish something for free and get real traffic from it. It is also a gatekept library: every submission is reviewed by a human, and the guidelines are stricter than the form suggests. We have submitted templates from a self-hosted instance, and this is the checklist we work from — what the review actually looks at, in the order it tends to matter.

The submission itself happens at creators.n8n.io, not in the n8n app. You register a creator account, verify the e-mail, and submit from the dashboard. Everything below is drawn from the official template submission guidelines and the separate sticky-note guidelines; if a rule here contradicts what you read there, trust them, not this post.

The one-template rule that surprises everyone

A new author (an account that has not been verified yet) may have exactly one template under review at a time. The button for the next submission stays disabled until the previous one is approved or sent back. There is no queue, no batching, and no way to speed it up from your side.

That single rule changes how you plan a set of templates. If you have three workflows ready, do not polish all three in parallel and hope to ship them in a week: you ship one, wait for review, then start the next. It also means the first submission is disproportionately expensive — a rejection costs you a full review cycle, so it is worth spending the extra hour on the sticky notes.

After three approved templates the account becomes verified. Verified authors get a badge, batches of up to four submissions instead of one, access to the closed n8n Discord, and the right to publish paid templates. Getting to three is the actual goal; the individual templates are the mechanism.

Titles: "action verb + object + where or from"

The title formula is not a style preference, it is a review criterion. Send website form leads to Google Sheets and Telegram is accepted shape: verb (Send), object (website form leads), destinations (to Google Sheets and Telegram). Ultimate AI Automation Beast 🚀 is not, for three separate reasons.

Practical consequences:

No emoji and no hype words. "Powerful", "ultimate", "revolutionary", "10x" all read as marketing rather than description.
Name the services concretely. "Your CRM" is vague; if the workflow talks to HubSpot, say HubSpot. Reviewers are checking that the title describes what the JSON actually does.
Keep it under the limit and check the rendered length. The library truncates on cards, and a truncated title loses the "where" half of the formula.

Our own three titles, for reference:

Send website form leads to Google Sheets and Telegram
Send a daily sales report from your CRM to Telegram
Answer customer questions from your knowledge base with an AI model

The description is a 200-word structured document

The description is English markdown, roughly 200 words, and it is expected to have sections, not a paragraph. The shape that reviewers look for:

Who it is for — the reader's job, not the workflow's features.
How it works — the steps in order, in prose.
How to set up — what to click, in what order, after import.
What you need — the services, credentials and plan requirements.
How to extend — an honest pointer at the part that is designed to be edited.

No HTML. Emoji are tolerated in the body far better than in the title, but the markdown has to render cleanly in the library's own renderer, which is stricter than a GitHub README — nested tables and raw HTML tend to come out mangled.

Sticky notes are mandatory, and one of them is not a note

This is the requirement people skip, and it is the one that gets a template sent back. Sticky notes in the workflow are not optional decoration: they are how the reviewer (and the person who imports your workflow six months from now) understands it without opening a single node.

The rule has two halves:

One yellow note carries the whole description. Not a summary — the full text that also goes into the submission form. The yellow note is the canonical copy.
Every other note is a neutral, step-level annotation — "Validate the e-mail before writing to the sheet", "Retry once on 429". They describe the step, not the template.

If you keep the description in two places, they will diverge within a week. In our repository the submission description is generated by a build script that reads the description straight out of the workflow's own yellow sticky note, so the form and the JSON cannot disagree. If you write your own tooling, do it in that direction: JSON is the source, the form is the copy.

Node names are read as documentation

The default n8n names (Set, HTTP Request, IF) tell a reader nothing. Renaming is expected, and it is checked: a workflow where the AI branch is labelled Normalize lead fields and Score against ICP rules is reviewable in a screenshot; one with four Set nodes in a row is not.

The same logic applies to sticky notes that arrange the canvas into sections — they should name the stage of the pipeline, not repeat the node names.

Nothing secret, nothing personal, nothing live

The exported JSON is public the moment it is approved, so review looks for anything that leaks or breaks someone else's instance:

No API keys or tokens anywhere in the workflow, including inside HTTP Request node headers, query parameters and JSON bodies. This includes disabled nodes — reviewers open those too.
No personal or tenant identifiers: real spreadsheet IDs, channel IDs, chat IDs, calendar IDs, e-mail addresses, internal hostnames. A real spreadsheet ID in a template is both a privacy problem and a broken template for everyone else.
Webhook paths should no longer be live. Rename them if the original path was reachable.
Credentials should not be embedded. Our exported workflows deliberately contain no credential blocks at all — the import dialog then asks the user to attach their own credential to a named node, which is the behaviour you want.
Replace placeholders with obvious placeholders. We use REPLACE_WITH_YOUR_CHAT_ID, REPLACE_WITH_YOUR_TOKEN, YOUR-N8N-HOST and example.com — strings that are unmistakably not real values, and greppable in the documentation.

A template whose HTTP node contains only a token placeholder and a documented "attach the credential here" step is also one your own account survives: the JSON in a public repo should not be the JSON that runs your production.

Preparing the JSON

The template artefact is a single exported workflow file, and preparing it is a mechanical pass:

Build the workflow in a clean project. Not in the instance where it already runs with live credentials.
Rename every node, describe every stage, add the sticky notes.
Strip credentials and replace every environment-specific value with a placeholder.
Check that it imports into a fresh instance: Workflows → ⋯ → Import from File. If a node shows a red error badge before you have attached anything, the template will be sent back.
Test the happy path with a real credential, and keep the curl invocation that exercises it in the template README.
Export, then re-import the exported file and read it once more. This catches the placeholder you replaced in the wrong branch.
If you used a community node, the submission needs a top image — a screenshot of the workflow canvas with the sticky-note sections visible works best. Workflows that use only built-in nodes (ours do) do not need one.

Publishing the same JSON in a public repo alongside the submission gives reviewers and users the same source of truth, and gives you a licence statement to point at — ours is MIT.

What reviewers are actually filtering for

Two prohibitions are worth stating explicitly because they are instant rejections rather than fixable notes: plagiarism (a renamed copy of an existing library template) and low-effort templates (one node wrapping one API call, or a workflow that only works after the user rewrites half of it).

The practical test we apply before submitting: would this still be useful to someone who does not use our service, and does every node in it earn its place? Our own submissions are business reporting and lead-intake workflows built on that standard, and the ones that touch our transcription HTTP API are documented so that the API call is one clearly-labelled step rather than the whole template.