We got this wrong for a while, so this post is partly an explanation and partly an apology.
The original submission form asked for one thing: a product URL. Paste it, we read the page, you confirm the details. Clean flow, worked nicely — for products that have a website.
Then we talked to n8n builders and found the obvious thing we had missed. Most of them have not built a website, because most of them have not built a product. They have built a workflow that saves their team six hours a week, or a community node that fills a gap in the core integration list. Those live as JSON files and npm packages. There is no landing page to read and no site to put a badge on.
So there are now three listing types. Here is how to pick.
Tool or product
You have a website. There is a homepage, probably pricing, probably docs.
This is the original flow and nothing about it has changed: paste the URL, we read the page and draft the listing, you correct whatever we got wrong. You get an embeddable badge at the end, because you have somewhere to embed it.
Choose this even if the product is free and even if it is a side project. The test is whether a website exists, not whether money changes hands.
n8n workflow or template
You built something on the canvas and want to share it. There is no website and there never will be one.
Paste or upload the workflow JSON. We read it and fill in what we can: how many nodes, what the trigger is, which integrations it touches. Those become your tags automatically, which matters more than it sounds — most people find workflows by searching for the app they need to connect, not by name.
Add a title, a description of what problem it solves, and a link to your GitHub or X profile so people can find more of your work. A screenshot of the canvas helps a lot; it is the fastest way for someone to judge whether a workflow is the shape they need.
One thing worth being careful about: strip your credentials before you export. n8n does not include credential values in the JSON, but it does include credential names, and people put customer names in those. Check before you paste.
There is no badge for this type. There is nothing to put it on, and offering one anyway would just be noise.
Community node
You published an npm package or a public repo that adds nodes to n8n.
Paste the npm URL or the repository URL. We pull the package name, description, version and links from there. You confirm and add anything the registry does not know — mainly what it is actually for, since npm descriptions tend to be terse to the point of unhelpful.
Node listings do get a badge, because a README is a perfectly good place to put one, and a directory link from a README is worth having.
Why not just one flexible form?
We tried sketching that. It ends up as a long form with half the fields greyed out and a lot of "leave blank if not applicable", which is the kind of thing that makes people abandon a submission halfway.
Asking one question first — what are you listing? — means each path can ask for three or four things and nothing else. It is a bit more work for us and noticeably less work for you.
What this does not change
n8n is still a first-class category here, with workflows, nodes, hosting and tools underneath it. What changed is that the site no longer assumes a listing must be a product with a homepage. That assumption was quietly excluding the most interesting half of the ecosystem.
Where to go next
Once you know which of the three you have, the submission form takes you down the right path from the first question. Submit your n8n project and pick the type that matches — workflow, community node, or product.
Worth a look first: the n8n category and its three sections — n8n Nodes, n8n Templates and n8n Hosting. Seeing where comparable projects landed is the fastest way to place your own.