KDPika Licensing
Sign inStart freeThis changelog records verified contract snapshots; documentation publication is not a new payment or licensing release.
What you will learn
- Distinguish API contract documentation from SDK/product release versions.
- Find verified changes without invented historic dates.
Prerequisites
- Read API conventions.
- Complete the Sandbox quickstart.
2026-10-17: complete v1 reference snapshot
The current source registers11 licensing operations: public-key retrieval, creation, activation, validation, deactivation, scoped retrieval, revoke, suspend, restore, renew and reset-devices. The reference records25 response/request components, exact credentials/scopes,69 per-operation error examples and the documented current headers. This entry describes the P6 authoring snapshot, not an API behavior change.
The local contract suite captures all 11 successes and22 API/router error identifiers. Two creation-idempotency defects remain disclosed rather than silently corrected. SDK versions are separate from API v1; the currently audited official packages identify version 1.0.0.
No earlier API release date is reconstructed from undocumented assumptions. An older file timestamp is not evidence that a behavior was deployed on that date.
Change entry format
| Field | What to record |
|---|---|
| Date | Actual verified publication/deployment date in UTC |
| Affected contract | Version, operation, fields, statuses, headers or error codes |
| Compatibility | Additive, documentation correction or breaking; explain why |
| Migration | Required client change, test vectors and upgrade guide |
| Evidence | Source commit and tested Sandbox response without secrets |
| Announcement | Actual notification channel/notice dates, not a presumed SLA |
A future entry must distinguish documentation correction from a changed server contract. Do not list a proposed feature as an available operation.
Known limitations
The current API has no historical signing-key ring, no list/customer/product CRUD surface and no universal mutation replay. Existing canonicalization/cache and idempotency issues remain visible in the security/reference guides. This page does not close those product findings.
Expected result
You can identify the documented v1 snapshot without confusing it with an SDK upgrade or an unverified production release.
Common mistakes
- Treating this reference date as the original API launch date.
- Calling a documentation correction a payment/security product fix.
Security notes
Changelog examples and evidence must exclude secrets, customer data and internal URLs. A change entry is not a compliance or uptime claim.
Troubleshooting
| Symptom | Cause | Action |
|---|---|---|
| Client behavior differs | Different package/server revision or documented limitation | Compare operation/schema and preserve request ID |
| No historic entry | No verifiable release evidence | Ask support rather than infer a date |
Next steps
Review the endpoint reference and signature verification.