Release Configuration and Reviewability

Requirements for plugin packages, manifest.json, release settings, and review information.

Every submission must open safely and include the basic configuration and information required for review. A package that cannot be extracted, lacks required settings, or is still configured as a development build will block the current submission.

Submit a Valid Package

Use Eagle to create the .eagleplugin file and confirm that:

• the file opens and extracts completely without corruption;

• the archive contains no duplicate paths, unsafe links, or paths that could write outside the plugin directory;

• it is the final release package, not another archive format with a renamed extension;

• it still installs correctly after being downloaded or moved.

An invalid, corrupted, or unsafe archive cannot proceed to further review. Rebuild it from a clean release directory instead of manually modifying an existing .eagleplugin file.

Place manifest.json in the Plugin Root

The release must meet these minimum requirements:

• manifest.json exists in the plugin root;

• the file contains a valid JSON object;

• id and name are non-empty strings;

• devTools is not set to true.

All other fields must match the plugin type and actual behavior. See manifest.json Configuration for the complete format.

Submit a Release Build

The release must not enable developer tools or depend on paths, services, or environment variables available only on the developer's computer. Install the packaged file before submission and verify that it runs without the original project directory.

If the plugin supports only certain operating systems, Eagle versions, file formats, or companion software, disclose that limitation in the store introduction. A limitation is not automatically disqualifying; failing to disclose one that prevents core use is a problem.

Provide Reproducible Review Instructions

No additional review document is normally needed when the plugin works without special setup. Provide steps in the submission notes or a README in the plugin root when the plugin requires:

• sign-in, an API token, a license key, or a review account;

• a server, third-party application, or local integration tool;

• system configuration changes or additional permissions;

• specific test files, data formats, or an essential sequence of actions;

• payment, a subscription, or a trial to complete the core flow.

The instructions must let a reviewer reproduce the main workflow. Review accounts must remain valid during review. Provide test credentials through the submission page; do not include real credentials, secrets, or user data in the package.

Common Reasons a Submission Does Not Pass

• manifest.json is missing from the plugin root or cannot be parsed.

• id or name has no valid value.

• devTools is set to true in the release.

• The .eagleplugin file is corrupted or cannot be safely extracted.

• Core functionality requires authentication or a special environment, but no usable review method is provided.

After correcting these issues, rebuild the package and test a fresh installation before resubmitting.