Skip to content
SignoxSignox Wiki

Online Activation

Online licensing is where the SDK communicates with the Signox server to receive a signed license state and stores it locally.

Flow

Section titled “Flow”
End user Your app · SDK Signox server ① Enter license key ② Activation request — key + device identifier ③ Ed25519-signed license state ④ Verify signature, store locally Works afterward without network
  1. The end user enters a licenseKey in your app.
  2. The SDK requests activation — it handles device identification and signature verification for you.
  3. The server registers the device (and checks limits) and returns the signed license state.
  4. The SDK stores the state locally. From then on it works without a network connection, relying on the locally stored signed state.

Activation rules

Section titled “Activation rules”
Rule Behavior
Idempotent re-activation Activating again on the same device reuses the existing registration — no additional slot is consumed
Device limit Once the number of active devices reaches the policy’s maxDevices, you get DEVICE_LIMIT_REACHED
Device matching See Device identification — swapping components counts as the same device, replacing the motherboard counts as a new device
VM policy When a VM/emulator is detected, it is allowed / flagged / blocked (VM_NOT_ALLOWED) according to policy

Validation on startup and local cache

Section titled “Validation on startup and local cache”

Validate with the SDK at app startup, but you don’t have to depend on the network every time:

  • On successful validation the server also returns a cache TTL hint (included in the signature), and the SDK trusts the local state for the duration of that TTL.
  • If the network is unavailable, it operates on the locally stored signed state (including the expiration date) — a single online activation is enough to enable offline runs afterward.
  • As expiration approaches, the TTL is automatically shortened so renewal is checked more frequently.

Heartbeat (optional)

Section titled “Heartbeat (optional)”

If you call the SDK’s heartbeat periodically:

  • you can see each device’s last-active time in the dashboard, and
  • you can detect revoked (revoke) or suspended (suspend) licenses earlier.

It is not required — skipping it has no effect on validation or activation.

Deactivation (moving devices)

Section titled “Deactivation (moving devices)”

When an end user switches devices, deactivate the old device to return its slot, then activate on the new device. Deactivation is possible from three places:

  • inside the app via the SDK (offering a deactivate button is recommended)
  • by the end user in the self-service portal
  • by the vendor in the dashboard

Status codes

Section titled “Status codes”

The code value in the SDK’s validation result:

VALID IN_GRACE_PERIOD EXPIRED SUSPENDED REVOKED valid: true valid: true — renewal notice ended recoverable permanent expiration date passed grace period passed suspend ↔ restore revoke — permanent, not recoverable
Code valid Meaning
VALID ✅ Normal
IN_GRACE_PERIOD ✅ Expired but within the grace period — keep features enabled, but prompting for renewal is recommended
EXPIRED ❌ Expired (grace period also passed)
SUSPENDED ❌ Suspended (recoverable)
REVOKED ❌ Revoked (permanent)
DEVICE_LIMIT_REACHED ❌ Device limit exceeded — prompt to deactivate an existing device
DEVICE_NOT_ACTIVATED ❌ Not activated on this device
VM_NOT_ALLOWED ❌ Blocked by VM policy
NOT_FOUND ❌ Nonexistent key

Usage reporting (metering)

Section titled “Usage reporting (metering)”

If you set up an int-type feature as metered (for example, monthly export count), you can report usage and check limits through the SDK. When the limit is exceeded, USAGE_LIMIT_REACHED is returned and the counter is not incremented; it resets automatically when the period (month/day) rolls over.