Guide
Storing Plugin Activation State
What to store after activation, what never to store, and how local cache affects startup validation and offline grace.
SoundSync
Cache fields
Custom HTTP field concepts, not the generated JUCE cache schema. Use the maintained JUCE runtime to store and verify its native state; separate product, device and test/live records.
| Field | Use | Rule |
|---|---|---|
| license_key | Required for serial flows | Sensitive. Encrypt/redact. Delete on deactivation. |
| instance_id | Required | Machine identity. Must match current machine. |
| token | Optional but used for validation fast path | Sensitive validation token. Rotate when server returns a new value. |
| status | Required | Describes the last decision; a stored status alone cannot authorize offline access. |
| activationId | Optional | Useful validation identity. Delete on deactivation. |
| licenseReference | Optional | Useful validation identity. Delete on deactivation. |
| productId | Required | Must match current product config. |
| graceExpiresAt | Optional | Server deadline from successful activation/validation. In JUCE it must match a verified signed grant; the timestamp alone cannot unlock. |
| offlineLease | Required for JUCE offline access | Opaque signed offline_lease from the API. The maintained JUCE runtime stores and verifies it; do not construct or edit it. |
| offlineGraceDays | Optional | Display/diagnostic value. Do not use to reset grace locally. |
| subscription_* fields | Optional | Display/status values. Explicit inactive/payment-required states lock. |
A signed grant is not an editable cache date
The current JUCE 0.7.3 package maps the API offline_lease to its opaque offlineLease state. Its verifier checks the trusted public key, signature, issuer, product, activation, device and expiry. Neither status: activated nor a future graceExpiresAt can replace that verification.
An older unsigned cache requires successful online activation or validation before offline use. Do not hand-edit the native cache or delete a valid device activation merely to upgrade. HISEScript and custom HTTP have separate storage and authorization contracts.
SoundSync
Sanitized activation record
Illustrative custom HTTP record, not a serialized JUCE cache. The offlineLease placeholder is deliberately not a valid signed grant and cannot authorize access. Use protected platform storage and atomic writes rather than saving this example as plain JSON.
{
"schemaVersion": 1,
"environment": "test",
"productId": 23794,
"appId": "ss_prod_demoapp123",
"license_key": "DEMO-SERIAL-0001",
"instance_id": "machine-demo-001",
"status": "activated",
"activationId": 123,
"licenseReference": "lic_demo_123",
"token": "validation-token-from-activation",
"graceExpiresAt": "2026-08-23T15:00:00.000Z",
"offlineLease": "ILLUSTRATIVE_PLACEHOLDER_NOT_A_VALID_SIGNED_GRANT",
"offlineGraceDays": 30,
"lastValidatedAt": "2026-07-24T15:00:00.000Z"
}SoundSync
Storage requirements
Local storage is part of the security boundary.
| Area | Requirement |
|---|---|
| Encryption | Use platform secure storage where possible. At minimum encrypt sensitive fields at rest. |
| Atomic writes | Write to a temp record and replace atomically to avoid corrupting the last valid cache. |
| Corruption | Treat corrupt or schema-invalid cache as locked; do not unlock from partial JSON. |
| Separation | Separate by productId, appId, environment, customer/account where applicable, and machine identity. |
| Deactivation cleanup | JUCE locks locally and persists deactivation intent immediately, then completes server deactivation online. Keep the local block authoritative across restarts; only server confirmation proves slot release. |
| Pending claim persistence | Store claim_id, license_key, instance_id, email, productId, and started time only while the flow is pending. |
| Never store | Customer passwords, plugin secrets outside generated config, or plugin key/secret in logs. |
Package-specific access policy
JUCE 0.7.3 supports signed offline access for the grace period selected in product Access settings, through 90 days. A prior successful activation or validation and the matching package verification keys are required. Startup uses a verified unexpired grant or online authorization. Zero, disabled, missing or expired grace requires online authorization; confirmed denial or deactivation locks access. Regenerate and rebuild older plugins to use this release.