KDPika Licensing
Sign inStart freeLicense status controls access, but status changes, expiry and device-seat release are distinct operations.
What you will learn
- Recognize every stored license state.
- Choose allowed management transitions.
- Understand why restore and reset do not undo every counter or token change.
Prerequisites
- Read authentication.
- Keep management keys only on a trusted server.
- Test transitions on a Sandbox license.
States and transitions
| State | Activation / validation eligibility | Allowed management actions |
|---|---|---|
| ACTIVE | Eligible if expiry, installation and applicable version rules pass | Suspend, revoke, restore as a same-state operation, renew |
| SUSPENDED | New activation rejected; active tokens revoked by suspension | Restore before expiry, repeat suspend, revoke, renew without removing suspension |
| PENDING | New activation rejected | Restore before expiry, revoke, renew without removing pending state |
| EXPIRED | Rejected | Renew to ACTIVE, revoke |
| REVOKED | Rejected; tokens invalidated | Repeated revoke only; no restore or renewal |
| CANCELLED | Rejected | No public cancel endpoint; no renewal or restore |
An elapsed expiry is checked before stored status during license eligibility. A future starts_at is currently included in signed data but is not enforced as a not-before boundary; do not use it to schedule a secure launch.
Management operations
| Operation | API path after /api/v1 | Effects |
|---|---|---|
| Suspend | POST /licenses/{license}/suspend | ACTIVE to SUSPENDED; invalidate active tokens, retain device rows |
| Restore | POST /licenses/{license}/restore | Eligible SUSPENDED or PENDING to ACTIVE; old tokens stay invalid |
| Revoke | POST /licenses/{license}/revoke | Allowed non-cancelled states to terminal REVOKED; invalidate active tokens |
| Renew | POST /licenses/{license}/renew | Add 1–3650 days to future expiry or now; EXPIRED becomes ACTIVE |
| Reset devices | POST /licenses/{license}/reset-devices | Deactivate active devices and revoke active tokens; preserve license status and cumulative activation count |
Current registered management uses the developer key scopes described in authentication. There is no public status=PENDING or status=CANCELLED command. Creation produces an active license.
Renewal details
Renewal refuses REVOKED and CANCELLED. A suspended or pending license keeps that state after renewal. A license with no expiry becomes time-limited when renewed with days.
Restore refuses an elapsed expiry; renew the eligible expiry first. Product plans marked monthly or yearly do not renew a customer license automatically when a payment occurs. Your own confirmed-payment backend must perform the intended licensing operation.
Expiry and scheduled work
Elapsed expiry blocks eligibility even before the scheduler updates the stored status. The current validation transaction rolls back its attempted EXPIRED write when it throws a rejection; a failed request is not itself durable proof of an expiration event.
The platform cron process durably records expiry and marks active tokens expired. Event/email delivery is queued operational work, not a prerequisite for denying an expired license.
A revoked, suspended or expired token can be rejected as INVALID_TOKEN. A fresh activation attempt can expose the corresponding license-state code. Do not assume every invalidation returns the same code on both paths.
Devices, events and audit history
Suspend and revoke invalidate tokens but do not release device seats. Deactivate or reset devices releases active seats. Restore requires fresh activation; an already-active matching device does not consume another cumulative activation merely because its token is refreshed.
Actual transitions publish corresponding supported events and record audit history. Repeated same-state management operations can record repeated activity. Do not treat them as a universal exactly-once/idempotency guarantee.
Expected result
You can suspend and restore an eligible Sandbox license, then re-activate it deliberately. Revocation is understood as permanent in the current lifecycle.
Common mistakes
- Revoking when a temporary suspension was intended.
- Restoring an expired license without renewing its expiry.
- Resetting devices to clear cumulative activations.
- Assuming disabling a product blocks every existing token: current validation does not enforce that product state consistently.
Security notes
Offline cached access cannot instantly learn about a server-side change. It ends at the applicable signed deadline or learns the rejection when it reconnects. Never extend an offline allowance from editable local state.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| INVALID_STATE 409 | Requested transition is forbidden | Review the current state; do not retry a permanent revoke as restore |
| Old token still fails after restore | Restore does not resurrect tokens | Activate again with an eligible license and persisted identity |
| Seat remains after suspension | Suspension is not device deactivation | Review and deliberately release the correct installation |
| EXPIRED not visible immediately in the list | Cron has not persisted the transition | Check the actual expiry; validation still rejects elapsed licenses |
Next steps
Read the complete activation flow and test its failure outcomes.