Guide
API Versioning and Deprecation
Current mixed versioning model across unversioned and v1 routes, generated package compatibility, additive changes, breaking changes, deprecation registry, and changelog expectations.
POST /activateGET /validatePOST /deactivate
Product credentials
Activation request
Entitlement check
Device registration
Periodic validation
Deactivation when needed
SoundSync
Policy summary
The machine-readable source is docs/contracts/api-deprecations.json.
| Change type | Policy |
|---|---|
| Additive field/endpoint | Allowed with docs and examples when public. |
| Breaking request/response change | Requires migration guide, changelog entry, release-gate update, and deprecation/sunset metadata when possible. |
| Legacy alias | Must remain labeled as alias/legacy and point to canonical replacement. |
| Emergency security change | May shorten timelines; docs/changelog must explain impact without exposing exploit details. |
| Generated package compatibility | HISE/JUCE package versions and endpoint paths must be represented in docs/tests. |