Repository navigation
Release v6.3.1
UltiTools-API 6.3.1
Install 6.3.1 only once UltiCloud has switched to protocol v2. 6.3.1 speaks only the new
UltiCloud protocol, and 6.3.0 is refused by the new gateway. Full details:
COMPATIBILITY.md and
the developer docs at https://dev.ultikits.com.
Before upgrading
- After the first start, run
/ulticloud loginagain. 6.3.1 deletes the 6.3.0cloud_tokenwith one
WARNING. The serveruuidis kept, so the panel can offer to re-attach the existing server. - Linking now uses a device code. The console prints a URL and an
XXXX-XXXXcode valid for 10
minutes; confirm it in the panel. The credential is stored in.ultikits/credentials.jsonand does
not expire. - UltiLogin's
/panelneeds UltiLogin 2.1.0. 2.0.0's/panelstops working on 6.3.1; its/loginkeeps working. - Modules that use XSeries directly must check the XSeries 14 API removals and recompile.
Changed
- UltiCloud client replaced: protocol 2.1.0 over
wss://api.ultikits.com/v1/agent, catalogue REST 1.1.0
under/v1/catalogue/*(#751, #763). New/ulticloud reconnect;/ulticloud statusnames the server. - New module APIs:
SensitiveCommandRegistry(redacts secret-carrying command arguments sent to UltiCloud)
andCloudPlayerLinks(one-time player links, replacing magic links). - XSeries 13.7.1 → 14.0.0 and HikariCP 7 (#737); jackson-databind 2.22.3 and log4j 2.25.4 (#765).
Fixed
- Server file operations protect the same files as the panel's protected list (#761).
- Served snapshot requests are audited (#758).
Deprecated
Every 6.3.0 public member that served only the old cloud is deprecated for removal in 6.4.0. It either
refuses explicitly or keeps doing what it says. No public API is removed; the list is in COMPATIBILITY.md.
Breaking changes
None in UltiTools-API's own public API. Runtime cloud behaviour changes without a migration period,
because the v1 cloud service stops at the switch.
🤖 Generated with Claude Code