KDPika Licensing
Sign inStart freeThese existing P2 integration notes describe unresolved behavior, not fixes or a production-readiness certificate.
What you will learn
- Identify signature and feature-guard limitations in the maintained SDKs.
- Understand current token storage, runtime and key-rotation boundaries.
- Avoid assuming an ambiguous creation error means no license was created.
Prerequisites
- Use synthetic Sandbox data for integration testing.
- Keep developer API keys on trusted servers, not distributed client applications.
Validity before features
Always require result.valid or Valid before reading any feature. Legacy/source SDK feature helpers may return a stored value when the result is invalid. Python 1.1.5 helpers fail closed, but keep the explicit validity and signature gate in your application. No failed-verification or invalid result should unlock paid features.
Published Python package
Python 1.1.5 is available on PyPI with MIT-licensed GitHub source. Use Python 3.11–3.14, import kdpika_licensing and follow the current Python guide. Earlier Python number/Unicode canonicalization defects are corrected; this does not change the other SDKs.
Signature and cache compatibility
JavaScript can reject signatures containing PHP integral-float values such as 19.0. C# can reject valid signatures after cached JSON re-encodes Unicode. Test actual server responses and cache round trips. Do not disable Ed25519 signature verification to work around a failure.
Runtime and storage
PHP source requires PHP 8.2 syntax although the current Composer constraint says 8.1. Python can use an optional usable OS keyring. PHP, JavaScript and C# currently use permission-protected files, not built-in native credential stores. File permissions are not encryption or protection from the owner of a machine.
Rotation and offline boundaries
Only the current signing key is published; no historical-key overlap is implemented. Pinned clients need coordinated updates. Offline access requires a previously verified response within its validity and grace deadlines. An authoritative server rejection does not permit an offline fallback. A user who controls a computer can patch a local application.
Creation idempotency and retries
Creation replay records retain the returned license key for 24 hours. The create and replay-storage operations are not atomic. A retry using an expired record can fail after another license has committed; concurrent requests can race. Investigate an ambiguous outcome with support before issuing another license. Do not assume exactly-once business fulfillment.
Environments, allowances and time
Missing activation environment headers default to Sandbox. Developer API keys and activation tokens determine their own environment. Products and product plans are shared configuration; usage allowances aggregate both environments.
Product and active-license creation limits are enforced. Monthly API usage is monitored with warnings, while platform device/member figures are not separate activation gates. Per-license device limits are enforced. Support-level labels are not response-time promises.
PHP uses UTC, but the database connection does not normalize its session timezone. Non-UTC database hosts can produce inconsistent timestamp interpretation; review actual hosting configuration before relying on dates.
Expected result
Your application rejects invalid license results and signature failures. Your release checklist includes real response and cache tests rather than relying only on a mocked SDK lifecycle test.
Common mistakes
- Reading a true feature value without checking the license result first.
- Retrying an ambiguous creation blindly and issuing duplicate licenses.
- Treating an optional keyring as guaranteed native secure storage on every computer.
Security notes
Never send API keys, activation tokens or full license keys in documentation feedback. Report a suspected vulnerability privately through support. These disclosures do not establish a certification or eliminate the need for independent review.
Troubleshooting
| Symptom | Current possible cause | Safe action |
|---|---|---|
| Valid server signature rejected in JavaScript | Integral-float serialization differs | Reproduce with synthetic data; do not bypass verification |
| C# cache fails after a restart | Unicode serialization differs | Test a cache round trip and report the failure without secrets |
| Create returns an ambiguous error | License may already have committed | Inspect the operation before creating again |
| Cached expiry looks offset | Database session timezone is not normalized | Review host timezone and actual timestamps |
Next steps
Read Using the documentation and contact support about a release blocked by these limitations.