CommandAPI: a Bukkit and Spigot API for Minecraft's command UI

The problem is that 1.13 changed what a command looks like

CommandAPI is a Bukkit and Spigot API to use the command UI introduced in Minecraft 1.13. The primary language is Java and the licence is MIT.

The context matters more than the description suggests. Minecraft 1.13 rewrote the command system around Brigadier, a command parser tree with typed arguments, and that change broke the conventions plugin authors had used for years. A plugin that registered a command with a hand-rolled string parser stopped working the way it did, and every plugin that wanted Brigadier's behaviour had to learn Brigadier's model directly, including its argument type system and its suggestion mechanics.

CommandAPI is an abstraction over that. A plugin declares a command with named arguments and a type, and the library handles the parsing, the conversion, the permission checks and the tab completion that the vanilla client sends as suggestions.

The audience is a plugin developer on Bukkit or Spigot, and the site commandapi.dev carries documentation that the README explicitly notes includes usage for server owners, so both audiences are addressed.

What the project is not is a way to run commands on the server. It is a library for defining them, and everything about its structure follows from that: it is versioned against Minecraft releases, it is a Gradle build with many modules, and it maintains a compatibility matrix rather than a single stable release that works everywhere.

The compatibility table is the product's most useful page

The README devotes most of its visible length to a table mapping Minecraft versions to CommandAPI versions and to the minimum Java version needed. It is unusual documentation, and it is the most important thing in the project for an adopter.

The rows show how wide the support actually is and how the versioning has moved. For Minecraft 1.13.x the compatible CommandAPI versions are v1.0 to 5.12 and 8.3.0 to 8.8.0, with the latest compatible being 8.8.0 and a minimum Java of 16. For 1.14.3 and 1.14.4 the range starts at v2.1, still requiring Java 16. For 1.16.1 it starts at v3.0, and for 1.16.2 at v4.0.

The Java floor moves with the Minecraft generation. The 1.19.x rows all require Java 16, while the 1.20 rows and the 1.21 rows require Java 17, with the latest compatible CommandAPI being 12.1.0 across 1.20, 1.20.1 and the 1.21 series.

Two things follow from reading it. First, the library has kept a version line alive for every Minecraft release since 1.13, which is a maintenance commitment a smaller library would not make. Second, the compatible versions column is a list, not a single answer, which tells you that a single CommandAPI build usually supports a range of Minecraft versions but not all of them, and that you pick the release that covers the versions you need.

The project releases on a version of its own: 12.1.0, 12.0.0 and 11.2.0 in the recent tag list, with 12.1.0 tagged on 2026-09-26 and the last push to the repository on 2026-10-20. The homepage is commandapi.dev.

A multi module Gradle build, with Kotlin bindings and a preprocessor

The repository structure shows the scope of the project, and it is larger than a single library.

There is commandapi-core, which is the implementation, and commandapi-plugin, which is the artifact a plugin actually depends on. There is commandapi-annotations and a separate annotations_spec_doc.md at the root, which suggests the annotations are a documented specification rather than an implementation detail. There is commandapi-kotlin for Kotlin bindings. There is commandapi-codecov, which is the coverage reporting module, and commandapi-testing, which is the test harness. commandapi-preprocessor is the code generator, and commandapi-platforms holds the per platform pieces. There is a buildSrc/ directory, which is where custom Gradle build logic lives, and a scripts/ directory.

The build is Gradle with Kotlin DSL, evidenced by build.gradle.kts and settings.gradle.kts alongside the gradle wrapper, and there is also a pom.xml and a jitpack.yml, so the project is publishable to Maven Central and consumable through JitPack as well. The Maven Central coordinates in the README badge are dev.jorel:commandapi. The publish.sh script handles the release, and changelog.md tracks changes.

The presence of commandapi-platforms is the interesting architectural decision. Modern Minecraft server software is not one platform, and a library that has to work against more than one of them needs to isolate the differences somewhere. Splitting the platform-specific code into its own module means the core does not carry the conditionals.

There are two spec documents at the root, annotations_spec_doc.md and velocity_spec_doc.md, and examples/ with a bukkit directory and a velocity directory, plus a build.sh. The Velocity example is a hint that the project reaches beyond Bukkit and Spigot, which is consistent with the nms and paper tags in the repository topics.

NMS is the hard part, and the shell scripts admit it

The topic tags include nms, which is the shorthand plugin developers use for the server internals that Spigot hides. A library like this has to interact with server internals to some degree, and doing that across many Minecraft versions is where the difficulty lives.

The shell scripts at the root show the workflow for that. There is compileNMSCommon.sh, setupPaperNMS.sh, resolve-snapshots.py, testAllVersions.sh and update.sh, alongside the Gradle build.

The names tell the story. setupPaperNMS.sh is about preparing a Paper NMS environment, compileNMSCommon.sh is about compiling the shared NMS pieces, resolve-snapshots.py is about resolving snapshot artifacts, and testAllVersions.sh is about running the test suite across the version matrix rather than against a single Minecraft version.

That last one is the meaningful one for an adopter. The compatibility table in the README is not a claim; it is the output of a build that compiles and tests against many versions. A library that supports a dozen Minecraft versions has to be able to build and verify against all of them, and the presence of a dedicated script for that is a good sign about the engineering behind the compatibility claims.

It is also a cost. This is not a library you drop into a build and forget. It is a library whose own build system knows about version-specific internals, and that has implications for anyone who wants to fork it or contribute to it, because the contributor workflow requires understanding the NMS setup.

The continuous integration is visible in the README badges, with a build workflow for the master branch and a separate one for a dev/dev branch, plus a CodeFactor grade badge and a Discord for discussion.

Picking the right release before you add the dependency

There is no install command in the README, and the reason is that the correct dependency depends on which Minecraft versions you support.

The library is published to Maven Central under the dev.jorel group, and the README badge points at the dev.jorel:commandapi coordinates, so the dependency to add is that coordinate with the version you pick from the table. Plugin authors depend on the commandapi-plugin module rather than the whole set of modules, and the project also publishes a pom.xml and a jitpack.yml so the library can be consumed through JitPack if your build is set up that way.

The compatibility table is the thing to read before you pin a version, because the answer is a range rather than a single number.

So for a server on 1.20 or 1.21, the newest release, 12.1.0, covers it, and the minimum Java version required to run that release is 17. For an older 1.19 server the answer is different, because those rows list 9.7.0 as the latest compatible and ask for Java 16.

Two practical notes for the first run. The documentation site, linked from the README, includes usage for server owners, so it is the place to check the setup for a specific server flavour. And the project publishes through several channels, so you can consume it from Maven Central or JitPack in the build, or install the plugin from the Spigot, Modrinth or Hangar pages if you are a server owner rather than a plugin author.

Where CommandAPI is the wrong tool

The first wrong-tool case is a server that is not Bukkit or Spigot based. The description is explicit that this is a Bukkit and Spigot API, and the topic tags name bukkit-api and spigot-api. A plugin written against it assumes the Bukkit command and permission model, so it does not transfer to a different server platform without a rewrite, even if the same underlying Brigadier parser exists there.

The second case is a plugin that has to run on a very wide Minecraft version range without pinning. The compatibility table shows that a single CommandAPI release covers a range of Minecraft versions, but it is never all of them. A plugin author who wants to support everything from 1.13 to the newest release has to build against an older CommandAPI line and accept the older feature set, because the newest line requires Java 17 while the older Minecraft versions want Java 16 or lower.

The third case is a project that wants a supported commercial product with an SLA. This is a volunteer project with a Discord, a documentation site and a good-faith effort, and its compatibility promises are the maintainer's own. A studio shipping a paid server product would want a different conversation about who answers when a new Minecraft release breaks the API.

There is also a dependency weight consideration. The library pulls in the NMS machinery and the platform modules, so a plugin that only needs a simple command with two string arguments is taking on more than it needs. The commandapi-plugin module is the artifact to depend on rather than the whole set, but it is still a large dependency with a version matrix attached.

On licensing, the project is MIT, which is the permissive grant a plugin author usually wants, and the LICENSE file sits at the root. Distribution is through several channels at once, and the README links a Spigot page, a Modrinth page and a Hangar page alongside the GitHub releases, so an adopter can pick the channel that fits their server's plugin approval process, and the download size and download count badges for Spiget, Spigot, GitHub and Modrinth give a sense of the project's reach across them.

Editorial conclusion

CommandAPI suits a Minecraft plugin developer who needs argument parsing, type conversion and tab completion that behave the way the vanilla client expects, and who is targeting more than one Minecraft version and needs to know exactly which release and Java version each requires. It does not suit a server that is not Bukkit or Spigot based, and it does not suit a plugin that has to run on the widest possible version range without pinning. Before adopting, read the compatibility table in the README for the exact Minecraft versions you support, and note that the versions are published under a dev.jorel group on Maven Central and distributed on Spigot, Modrinth and Hangar.

Frequently asked questions

Official sources

1. CommandAPI/CommandAPI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases