Verification guidelines

Use the n8n-node tool

All verified community node authors should use the n8n-node tool to create and check their package. This helps n8n ensure quality and consistency by:

• Generating the expected package file structure
• Adding the required metadata and configuration to the package.json file
• Making it easy to lint your code against n8n's standards
• Allowing you to load your node in a local n8n instance for testing

Node Types

• The node MUST not be an existing node, If your node is an iteration on an existing node create a pull request instead.
• n8n isn't accepting Logic or Flow control nodes at the moment.
• Each package should integrate exactly one third-party service. A trigger node for the same service may be included alongside the main node. Packages that wrap multiple unrelated APIs or act as a proxy layer for several services generally don't qualify for verification. Submit each service as its own separate package.

Package source verification

• Verify that your npm package repository URL matches the expected GitHub repository.
• Confirm that the package author / maintainer matches between npm and the repository.
• Confirm that the git link in npm works and that the repository is public.
• Make sure your package has proper documentation (README, usage examples, etc.).
• Make sure your package license is MIT.
• Packages should be published from a GitHub action and include provenance

No external dependencies

• Ensure that your package does not include any external dependencies to keep it lightweight and easy to maintain.

Proper documentation

• Provide clear documentation, whether it’s a README on GitHub or links to relevant API documentation.
• Include usage instructions, example workflows, and any necessary authentication details.

No access to environment variables or file system

• The code must not interact with environment variables or attempt to read/write files.
• Pass all necessary data through node parameters.

Follow n8n best practices

• Maintain a clear and consistent coding style.
• Use TypeScript and follow n8n's **node development guidelines**.
• Ensure proper error handling and validation.
• Make sure the linter passes (in other words, make sure running npx @n8n/scan-community-package n8n-nodes-PACKAGE passes).

Use English language only

• Both the node interface and all documentation must be in English only.
• This includes parameter names, descriptions, help text, error messages and README content.