UltiTools-API 6.3.1 Release Notes

6.3.1 replaces the framework's UltiCloud client. It speaks UltiCloud protocol 2.1.0 to wss://api.ultikits.com/v1/agent and links a server with a device code. The full list for module authors is in COMPATIBILITY.md; the release itself is v6.3.1 on GitHub.

Upgrade to reconnect

Since the UltiCloud backend cut-over on 2026-11-06, the new gateway refuses 6.3.0 servers (HTTP 426). A 6.3.0 server cannot reconnect to the panel, run /ulticloud login, use /panel links or check the module catalogue until it runs 6.3.1.

Before upgrading

• After the first start, run /ulticloud login again. 6.3.1 deletes the 6.3.0 cloud_token from .ultikits/credentials.json with one WARNING and keeps the server uuid, so the panel can offer to re-attach the existing server.
• Linking uses a device code. The console prints a URL and an XXXX-XXXX code valid for 10 minutes; confirm it in the panel. The credential is stored in .ultikits/credentials.json and does not expire. See Cloud Login.
• UltiLogin's /panel needs UltiLogin 2.1.0. The /panel of UltiLogin 2.0.0 stops working on 6.3.1; its /login keeps working.
• Modules that use XSeries directly must check the XSeries 14 API removals and recompile.

Changed

• The UltiCloud client is replaced: protocol 2.1.0 over wss://api.ultikits.com/v1/agent and catalogue REST 1.1.0 under /v1/catalogue/*. /ulticloud reconnect is new, and /ulticloud status names the server. See Panel Integration.
• SensitiveCommandRegistry lets a module keep the arguments of secret-carrying commands out of everything sent to UltiCloud (see Sensitive commands).
• CloudPlayerLinks creates one-time player links and replaces magic links (see Player Link).
• XSeries moves from 13.7.1 to 14.0.0, HikariCP to 7, jackson-databind to 2.22.3 and log4j to 2.25.4.

Fixed

• Server file operations protect the same files as the panel's protected list.
• Served snapshot requests are audited.

Deprecated

Every 6.3.0 public member that only served the old cloud is deprecated for removal in 6.4.0. Each either refuses explicitly or keeps doing what it says. No public API is removed.

Breaking changes

There is no binary break. A module compiled against 6.3.0 still links, because the erased method descriptors of PanelResponderRegistry.registerResponder and dispatch are unchanged (checked by comparing the 6.3.0 and 6.3.1 sources). The cloud features change their runtime behaviour without a migration period, because the previous cloud service stopped at the cut-over.

There are two source-level breaks in the panel responder API. A module that uses them must change its source before it recompiles against 6.3.1:

Member	6.3.0	6.3.1	What a module author changes
registerResponder(String, Function, String) and registerResponder(String, Function, String, UltiToolsPlugin), the responder parameter	Function<JsonObject, CompletableFuture<JsonObject>>	Function<JsonObject, ? extends CompletableFuture<? extends JsonElement>>	A lambda or method reference still compiles. A subclass that overrides either method must change its parameter type to the new one.
dispatch(String, JsonObject, String) return type	CompletableFuture<JsonObject>	CompletableFuture<JsonElement>	Change a CompletableFuture<JsonObject> variable that receives the result to CompletableFuture<JsonElement>, or cast the result.

The new dispatch overload with a fourth Runnable argument is an addition, not a break. See Owning a request/response type for the new contract.

Contributors

Ling Bao