Plugin Submission Guidelines
EndGit review focuses on safety, transparency, and usefulness. These guidelines are intentionally practical: they explain what reviewers look for, not how to write your plugin.
AWhat We Accept
Plugins should be useful, honest, and appropriate for public servers.
Useful for server owners
Your plugin should have a clear use case for Endstone servers. Small utilities, focused tools, and quality-of-life plugins are welcome as long as the description explains who it helps and why.
Be honest about scope
Experimental, beta, or server-specific features are allowed, but they must be clearly labeled. Do not present unfinished features as stable or production-ready.
Original work or permitted forks
Submit your own work, or a fork you are allowed to maintain. Forks and alternatives are allowed when they add meaningful changes, fix abandoned work, or explain how they differ from existing plugins.
No harmful or deceptive behavior
Plugins must not hide malicious behavior, mislead users, steal data, abuse permissions, or run code from remote sources to bypass EndGit review.
External services are allowed when transparent
Plugins may use external APIs or services if the dependency is clearly documented, failure is handled gracefully, and users can understand what data is sent outside their server.
BTechnical Quality
Code should be maintainable enough for review and safe enough to run.
Declare compatibility
Declare the supported Endstone API version and any required dependencies in the manifest and submission form. If a dependency is optional, document what happens when it is missing.
Readable source required
Reviewers must be able to inspect the source code. Obfuscated code, bytecode-only Python submissions, or missing C++ source may be rejected.
Keep startup output reasonable
Console output is fine when it helps diagnose setup or errors. Avoid noisy banners, repeated logs, or promotional output on every startup.
Use stable APIs when possible
Prefer Endstone APIs over raw protocol manipulation or fragile internals. Low-level approaches are acceptable when there is no practical API alternative and the reason is explained.
Names should not collide
Use distinctive plugin names, permission names, package/module names, and database table names so your plugin does not conflict with other plugins.
DDocumentation
Users should understand what the plugin does before installing it.
Explain the plugin clearly
Include what the plugin does, basic setup steps, important commands or permissions, and any known limitations. A short but clear README is better than a long vague one.
English summary required
The main description should include an English summary. Additional languages are welcome and encouraged.
Changelogs should help users
Updates should include user-readable changelogs for meaningful changes. Tiny maintenance-only updates can be brief.
License required
Include a license file so users know how the plugin may be used, shared, and modified. Open-source licenses are strongly preferred for marketplace trust.
SSecurity & Performance
These are the rules most likely to block approval because they protect servers.
Do not freeze the server
Long network calls, heavy file I/O, expensive database work, and large computations should not run on the main server thread.
Protect user data and credentials
Never log tokens, passwords, API keys, or private user data. Do not commit credentials to source code, and use encrypted connections for sensitive communication.
Prevent injection vulnerabilities
Use prepared statements or parameterized queries for SQL. Treat player input, config values, and external API responses as untrusted.
Clean up resources
Close database connections, cancel scheduled tasks, release file handles, and stop background workers when the plugin is disabled.
Use permissions for protected actions
Commands or actions that affect other players, economy, files, worlds, or server state should be protected by clear permissions.
Review Philosophy
Most issues can be fixed during review. Rejection is mainly for unsafe behavior, misleading submissions, missing source, or plugins that cannot reasonably be reviewed. If you are unsure about a guideline, ask on Discord before submitting.