Imported from Zoominfo/n8n-nodes-zoominfo (AGENTS.md). Install upstream with npx skills add Zoominfo/n8n-nodes-zoominfo. Copyright stays with the author.

n8n community node

Overview

This is a project containing code for an n8n community node. n8n is a workflow automation platform where users build workflows with nodes, which are the building block of a workflow. Nodes can perform a range of actions, such as starting a workflow (called a "trigger node"), fetching and sending data, or processing and manipulating it. Besides that there are credentials - entities that store sensitive information on how to connect to external services and APIs. A node can require some credentials to be used. Community nodes are a way for anyone to create such nodes and add them to be used in n8n. All community nodes are named in a format: n8n-nodes-<n> or @org/n8n-nodes-<n>. Community nodes can also be submitted for approval to be used on n8n Cloud version. In that case there are rules that the node needs to follow in order to be approved

Important notes

• Follow the rules and guidelines in this document and the linked docs below over any code examples.
• All code blocks in these docs are illustrative and incomplete. They MUST NOT be copied verbatim or assumed to be the final desired code.
• Replace example names like Example, Wordpress, wordpressApi, etc. with names that match the actual service / node you are building.
• When in doubt, generalize from the patterns, don't replicate the exact structure, fields, or values from the examples.
• Produce the full implementation needed for the current project (nodes, credentials, tests, etc.), not just fragments similar to examples.
• If an example omits parts (e.g. types, operations, properties), infer and implement the missing parts based on the real requirements / API docs.
• Never output Wordpress-specific code unless the project is actually about WordPress.

Project structure

There are two main folders in this project:

• nodes contains all of the nodes in a package (there can be more than 1). The code for each node usually lives in its own folder
• credentials contains all of the credentials in a package. Usually it's just a single file for every credential So it looks something like this: . ├── nodes/ │ └── Example/ │ ├── Example.node.ts │ └── ... ├── credentials/ │ └── Example.credentials.ts ├── package.json └── ... It's important to note that package.json has a special field n8n that have information about nodes and credentials in a package:

{
  "name": "n8n-nodes-example",
  "version": "1.0.0",
  "n8n": {
    "n8nNodesApiVersion": 1,
    "strict": true,
    "credentials": [
        "dist/credentials/Example.credentials.js"
    ],
    "nodes": [
      "dist/nodes/Example/Example.node.js"
    ]
  }
}

nodes and credentials keys contain paths to transpiled JS files in a dist folder for the nodes and credentials respectively. If you add/remove/rename nodes and/or credentials, you need to make sure to update n8n.nodes and n8n.credentials keys in package.json accordingly. Initial files in the project may contain example nodes and/or credentials that need to be removed or renamed once you start making an actual node.

Key guidelines

• Use the n8n-node CLI tool whenever possible for building, dev mode, linting, etc.
• Always address any lint/typecheck errors/warnings, unless there is a very specific reason to ignore/disable it
• Make sure to use proper types whenever possible
• If you are updating the npm package version, make sure to update CHANGELOG.md in the root of the repository
• Read .agents/workflow.md for more info

Commits and releases

Commit messages must follow Conventional Commits. This is not a style preference: .github/workflows/release.yml runs semantic-release, which reads the commit types since the last release to decide the next version. A commit that does not follow the convention is invisible to that calculation.

feat: add Company Enrich operation        -> minor
fix: stop Return All dropping the sort    -> patch
docs(README): correct the callback URL    -> patch
chore: bump eslint                        -> no release

Breaking changes take a BREAKING CHANGE: footer (or feat!:) and bump the major. When squash-merging a PR, the squash title becomes the commit message, so it has to follow the convention too — an unconventional title means the merged work never triggers a release.

Releasing is manual and takes no arguments: Actions → Release → Run workflow. There is no version to choose and no tag to push; semantic-release works out the version, publishes to npm with a provenance attestation, commits the bump back to main, and opens the GitHub Release. If nothing since the last release warrants one, it exits without doing anything.

Do not run npm publish locally. prepublishOnly blocks it, and a package published from a laptop carries no provenance, which disqualifies it from n8n verification.

CHANGELOG.md is not generated. No changelog plugin is configured, so update it by hand in the same PR as the change it describes.

Context-specific docs

Load these before working on the relevant area:

Additional resources

If you need any extra information, here are links to n8n's official docs regarding building community nodes:

• https://docs.n8n.io/integrations/community-nodes/building-community-nodes
• https://docs.n8n.io/connect/create-nodes/overview
• https://docs.n8n.io/connect/create-nodes/build-your-node/reference
• https://docs.n8n.io/connect/create-nodes/build-your-node/reference/ux-guidelines
• https://docs.n8n.io/connect/create-nodes/build-your-node/reference/verification-guidelines
• https://docs.n8n.io/connect/create-nodes/deploy-your-node/submit-community-nodes