Plugin Submission Rules
All plugins submitted to the EndGit Marketplace must comply with the following rules. Violations may result in rejection during review.
APurpose & Ethics
Plugins must be purposeful, original, and ethical.
Must serve a purpose
Plugins must serve a purpose that cannot be replicated using Endstone's built-in features. Plugins that only provide command aliases or shortcuts to built-in functionality will not be approved.
Serve a specific purpose
The plugin must serve a **specific** purpose and be useful to the majority of server operators. Core/private-server-only plugins are not accepted. Plugins containing many mutually irrelevant features bundled together ("kitchen sink" plugins) are also not allowed.
No duplicates
If an existing approved plugin covers every feature your plugin provides, you must not submit yours — unless the existing one has been unmaintained for **more than 30 days**. If submitting a competing plugin, explain why yours is better or different in the description.
No remote code execution
Plugins must not execute code fetched from remote sources at runtime. If the plugin requires an external API, it must be from a reputable provider or have high transparency. Auto-updaters that bypass EndGit's CI/CD pipeline are strictly prohibited.
No artificial limitations
Artificially created limitations (e.g., feature-gating behind paid plans, license keys, or subscriptions to unlock self-imposed restrictions) are not allowed.
No unsolicited advertisement
Plugins must not be used as a medium to advertise external servers, products, or resources unless explicitly requested by the user (e.g., through a help command). Reasonable contact information in the description is permitted.
Use of external APIs
External APIs (especially HTTP/HTTPS requests) should only be used when reasonably necessary, such as when involving a public database or large dataset that cannot practically be distributed with the plugin.
Availability of external APIs
Any external API used by a plugin must offer a free tier with a reasonable rate limit. Plugins that depend entirely on paid-only APIs will not be approved.
Libraries must be bundled
Shared libraries must be bundled with the plugin (e.g., statically linked for C++ or included as Python packages). Standalone "API-only" plugins that serve no purpose on their own are not accepted — convert them to libraries.
Only submit your own work
You may only submit plugins you have authored. To submit a fork of an abandoned plugin, you must provide proof of the original author's permission, or evidence that the original author did not respond within 14 days of a request to update. Forks must be submitted under a different name.
Complete and functional
Plugins must be complete and functional. Partially implemented features must be clearly marked as experimental and must not be listed as stable features in the description.
BTechnical Quality
Code must meet quality, readability, and compatibility standards.
Supported Endstone versions
Plugins must declare the minimum supported Endstone API version. Only officially released Endstone versions are accepted — development/nightly API versions must not be declared as requirements.
No obfuscation
Source code must be readable and not obfuscated. For C++ plugins, the source repository must contain the complete, readable source. For Python plugins, no bytecode-only submissions are allowed.
No unnecessary console output
Plugins must not output unnecessary status messages on startup/shutdown (e.g., "Plugin enabled!", "Author: Xxx", ASCII art banners). Console output is only acceptable if startup genuinely takes significant time (>1 second) or for critical error reporting.
Default language must be English
Multi-language support is encouraged, but the default language must be English. All command descriptions, help text, and console output must be available in English.
Political and religious neutrality
Plugins must not contain politically or religiously biased content.
Declare dependencies
All plugin dependencies must be declared in both the plugin manifest (plugin.toml / plugin.yml) and the submission form. Required dependencies that are not available on EndGit must not be used.
No hardcoded data
Plugins should use Endstone API methods and constants for vanilla game data where available. Hardcoded block/item IDs, entity type strings, etc. should be avoided in favor of API-provided constants.
Clean plugin name
Plugin names must not include version information (e.g., no "-v2", "-PM5" suffixes), must match the name declared in the plugin manifest exactly, and use only alphanumeric characters, hyphens, and underscores.
Use API over protocol
Plugins must not use raw packet handling to implement features that can be accomplished using the Endstone API. Direct protocol manipulation is only acceptable when no API alternative exists.
CNaming & Structure
Proper naming, namespacing, and structural conventions.
Unique namespace (C++)
C++ plugins must use a unique namespace that will not collide with other plugins. The recommended format is author_name::plugin_name. The author/org name should correspond to the GitHub username or organization.
Unique module name (Python)
Python plugins must use a unique top-level module/package name. The recommended format is author_pluginname or a similarly distinctive name that avoids collision.
Stay in your namespace
All classes, types, and symbols declared by a plugin must reside within the plugin's own namespace/package. Do not pollute the global namespace or other plugins' namespaces.
Command registration
All commands must be properly registered through the Endstone API. Commands must be associated with the registering plugin. Fallback prefixes must match the plugin name (no abbreviations or acronyms).
Permission naming
All permissions must start with the plugin name (lowercase), use only lowercase letters, digits, hyphens, and dots, and be consistently declared in both the manifest and code.
Data isolation
Plugin-specific data must be stored in the plugin's data folder. Entity/world-specific data must be stored in a namespaced compound tag. Database tables must use a plugin-prefixed naming convention to prevent collisions.
No hardcoded command dispatch
Plugins must not use command dispatch (dispatchCommand) to invoke other plugins' functionality. Use the proper API or declare explicit dependencies instead.
DDocumentation
Clear, complete, and well-formatted documentation.
Detailed description
The description must explain what the plugin does, why it is useful, and how to configure/use it. Do not assume the reader already knows the context. Screenshots or videos alone are not sufficient.
English description required
The plugin description must be available in English. Translations in other languages are welcome but English must come first.
Clean description
Do not include irrelevant, duplicated, or misleading information. Do not advertise external products. A reasonable number of contact links (Discord, GitHub) is acceptable.
Formatted description
Format your description using Markdown. Use headings, lists, code blocks, and screenshots to make the description easy to read and visually appealing.
Informative changelog
Every update must include a changelog with user-readable information about what changed. Do not include trivial entries like "fixed typo" or "updated README" without meaningful context.
Open source license required
All plugins must be published under an OSI-approved open source license. A LICENSE file must be present in the root of the repository. Choose your license carefully — it cannot easily be changed after submission.
SSecurity & Performance
Plugins must be safe, efficient, and well-behaved.
Do not block the main thread
Plugins must not block the server's main thread with long-running operations such as network requests, heavy file I/O, or expensive algorithms. Use std::async / thread pools (C++) or asyncio / threading (Python).
SQL injection prevention
All SQL queries must use parameterized queries or prepared statements. Never interpolate user input directly into SQL strings, even if the input appears to be validated.
No unbounded memory growth
Plugins must not allocate memory proportional to persistent quantities (e.g., total registered players). Do not load entire player databases into memory. Use pagination and implement proper cleanup/expiration.
Use permissions for access control
Do not intercept command events to block players from running commands. Use the permission system instead. Event-based command blocking is vulnerable to alias attacks and formatting exploits.
Secure credential handling
Plugins must never log passwords, tokens, or API keys to console, include credentials in source code, or transmit credentials over unencrypted connections. Sensitive configuration should be loaded from config files excluded from version control.
Resource cleanup
Plugins must properly clean up resources on disable: close database connections, cancel scheduled tasks, release file handles, and stop background threads. Failure to clean up can cause memory leaks and server instability.
⚠️ Enforcement
Violations of these rules may result in the plugin being rejected during review. Repeated or severe violations may lead to submission privileges being restricted. If you have questions about a specific rule, reach out on our Discord.