KDPika Licensing
Sign inStart freeStart from a complete application project, not a fragment that pretends to verify a license.
What you will learn
- Run six complete desktop/backend/CLI sample projects.
- Exercise activation, features, offline/refusal and deactivation.
- Understand exact storage, runtime and native-test boundaries.
Prerequisites
- Complete the Sandbox quickstart.
- Read signed responses, authentication and offline mode.
Current Python release
For Python SDK 1.1.5, install the PyPI package and use the versioned GitHub examples. Keep the adjacent _common.py helper. The Python CLI 1.0.0 ZIP below is a retained legacy project bundled with SDK 1.0.0; it is not the current PyPI release and its old dependency instructions are not recommended for a new project.
Six complete runnable projects
| Application | Complete source ZIP | Bytes | SHA-256 |
|---|---|---|---|
| python-cli (legacy SDK 1.0.0) | kdpika-python-cli-example-1.0.0.zip | 30069 | 3e4aac6849ec78e3fb75d715a00e4456145e6f36e5f67627814ec0caa0058d64 |
| electron | kdpika-electron-example-1.0.0.zip | 54905 | 47801b88c4b7c606fd9608ced391230daf967c8d91d9b9a05f8e0e699fd62dcc |
| php-backend | kdpika-php-backend-example-1.0.0.zip | 22371 | bdb3a8be5993b4f9f4657019ee9259068dce2c5df43e4038b356eb61082add12 |
| csharp-desktop | kdpika-csharp-desktop-example-1.0.0.zip | 23340 | e7c33a00760ae099714d235f4ba560542aa68ad8c36aa04306619ecd9531aab5 |
| go-cli | kdpika-go-cli-example-1.0.0.zip | 10171 | 80db0d99c204b18879d730512073c3f4616c713d83184b8a0b9fa4f2add2b058 |
| java-console | kdpika-java-console-example-1.0.0.zip | 12140 | 7bbcba603b2171487643bcafa5842b94d6816febcd6747bfeeadfd951b59c1e8 |
Every ZIP contains its README, complete application code and exact included SDK/client source. No populated state directory, customer key, activation token, private signing key or compiled unsigned binary is distributed. Package version1.0.0 here is a sample revision, not an additional official SDK release.
Choose an application
| Project | Entry and purpose | Actual verification boundary |
|---|---|---|
| Python CLI | main.py + complete session.py; official Python SDK | Real source CLI and frozen PyInstaller macOS executable; native Windows/Linux freeze not claimed |
| Electron desktop | main-process service, isolated preload and renderer | Real macOS source window and unsigned packaged window; no code-signing/notarization or encrypted-vault claim |
| PHP backend | Local authenticated session, CSRF and server-side feature action | Real loopback PHP/browser workflow including transport/refusal; intentionally not a public identity/multi-tenant system |
| C# desktop | Full Windows WPF project plus shared LicenseController | Windows-targeted cross-build on macOS and real Sandbox controller tests; native WPF UI requires Windows |
| Go CLI | Runnable shell entry to included native Go client | Fresh archive build and real lifecycle/offline/refusal checks |
| Java console | Runnable shell entry to included Java session core | Fresh archive build, pinned jars and real lifecycle/offline/refusal checks |
These are application examples, not a promised production product for every UI framework. The official SDK runtime behavior—including current signature/cache defects—remains unchanged. C# real Unicode cache rejection is an honest refusal/online recovery path, not a fabricated offline success.
Install the selected project
- Download the complete project ZIP and verify its SHA-256. Expected: the table digest exactly matches.
- Extract with the original layout. Expected: its README and all referenced SDK/client/verification sources are present.
- Install the exact dependencies from that README. Expected: local source install/build, not an invented registry SDK. Development compilers stay on your machine, not on KDPika shared hosting.
- Configure the Public App ID and absolute private state path. Expected: a Sandbox namespace isolated from other apps/buyers.
- Configure the independently trusted public key for Go/Java REST apps. Expected: controlled key trust before activation, not a key copied from an untrusted envelope.
- Start the application with synthetic Sandbox data. Expected: no feature access until a current valid signed result grants that feature.
Source and execution instructions
# Python CLI Sandbox application
Requirements: Python3.9+, exact bundled SDK1.0.0; cryptography46.0.3.
The archive contains the exact tested session.py beside this entry point, not a substitute SDK. Use .venv\Scripts\python.exe on Windows. The example deliberately selects file storage for reproducible tests, not a universal vault recommendation. clear-local never releases a server seat.
## Install and run
```sh
python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.txt
.venv/bin/python -m pip install --no-build-isolation ./kdpika-python-sdk
.venv/bin/python main.py status
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
# Electron desktop Sandbox application
Requirements: Electron44.9.0, electron-builder26.15.3, official JavaScript SDK1.0.0.
The complete exact SDK directory is included for the local file dependency. Electron44 resolves its binary lazily at first start. Only main-process service owns licensing; contextIsolation/sandbox are enabled and renderer Node integration is disabled. Safe decisions cross narrow checked IPC. File storage is not automatically safeStorage encryption. The unsigned macOS directory build is a test artifact, not notarized distribution or Windows/Linux execution proof.
## Install and run
```sh
npm ci
npm start
npm run package
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
# PHP backend Sandbox application
Requirements: PHP8.2+, cURL, Sodium capability and Composer-installed official SDK1.0.0.
This example rejects nonloopback callers. Set KDP_SDK_DIR to the absolute included SDK directory, KDP_STATE_DIR outside the served project and a random KDP_DEMO_ACCESS_CODE of at least24 bytes. Open the loopback URL, authenticate with the local access code and then activate/check. It uses real PHP sessions, CSRF tokens, safe output and server-side feature rechecks. It is not a production identity provider, public multi-tenant app or an instruction to deploy a local testing router.
## Install and run
```sh
composer install --working-dir ./kdpika-php-sdk --no-plugins --no-scripts
php -S 127.0.0.1:8200 -t .
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
# C# Windows WPF desktop Sandbox application
Requirements: Windows desktop UI; net7.0-windows project plus official net7 SDK1.0.0/Bouncy Castle2.7.0.
The exact SDK source directory is included for ProjectReference. Cross-build uses EnableWindowsTargeting on macOS; real WPF UI execution requires Windows and is not claimed on macOS. LicenseController.cs is shared verbatim between the UI and actual Sandbox controller tests. SDK Unicode cache rejection can prevent offline use for real server responses; fail closed, do not strip/re-sign data. .NET7 is an observed target, not a claim of continued vendor support or recommended maintained deployment.
## Install and run
```sh
dotnet restore Desktop.csproj
dotnet build Desktop.csproj
dotnet run --project Desktop.csproj
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
# Go CLI Sandbox application
Requirements: Go1.22+, standard library.
The complete project archive includes the unchanged tested samples/sdks/go tree alongside samples/apps/go-cli. The entry point builds and runs the native Go client, never a Python/Node subprocess. Preserve that relative layout. Third-party runtime modules are not needed.
## Install and run
```sh
sh run.sh status
sh run.sh activate
sh run.sh check
sh run.sh validate
sh run.sh deactivate
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
# Java console Sandbox application
Requirements: Java17+, Gson2.14.0, Bouncy Castle1.86.
The complete archive preserves samples/apps/java-console, samples/sdks/java and samples/security/java. Its shell entry uses the exact native JVM client and checksum-pinned build, not an invented registry SDK. Windows uses semicolon classpaths if running the Java command directly. No Python/Node runtime is required.
## Install and run
```sh
sh run.sh status
sh run.sh activate
sh run.sh check
sh run.sh validate
sh run.sh deactivate
```
Set KDP_APP_ID and an absolute private KDP_STATE_DIR through trusted configuration. Official SDK apps use KDP_BASE_URL as a site origin; Go/Java REST apps use the API base ending /api/v1 and require KDP_TRUSTED_KEY_FILE pointing to an independently trusted public-key document. Default is the official HTTPS service. Explicit local tests may use KDP_ALLOW_LOOPBACK=1; never arbitrary HTTP.
Use only a real Sandbox key (TEST prefix) and its matching email when supplying email. GUI apps collect these through fields; CLI apps read KDP_LICENSE_KEY/KDP_CUSTOMER_EMAIL privately from the environment. Never commit those values or use an lmp_ developer API key in an installed app.
## Demonstration sequence
1. Check fresh status or attempt a check. Expected: not activated; no feature access.
2. Activate with matching Sandbox data. Expected: accepted signed result or a clear refusal.
3. Check again. Expected: verified cache where eligible or online verification, never token-presence permission.
4. Validate online. Expected: actual signed decision; explicit server rejection never becomes offline permission.
5. Simulate transport loss only in an isolated test. Expected: accepted signed offline state inside grace, or fail closed when absent/invalid/expired. Current SDK limitations remain documented.
6. Test PDF export. Expected: enabled only after valid/signature/feature checks; PHP/WPF recheck on the action. The demonstration creates no invoice/payment or real PDF.
7. Deactivate. Expected: seat release, no feature grant and no token/cache left; stable installation identity remains.
## Privacy, recovery and limitations
Use private per-application state, serialize operations and preserve installation identity across updates. Files protected by permissions are not automatically encrypted OS vaults. Do not expose a raw token, SDK object, signed customer payload or arbitrary storage path through UI/IPC/HTTP. Never bypass a signature failure to make an offline example pass.
No mutation is automatically retried by these application entry points. A lost activation/release response needs reconciliation before retrying. Deactivation does not reset cumulative activation_count. Removing the app/package alone does not release a server seat. Deactivate online first and follow an explicit retention policy for exact app state.
Test inputs/refusals/outages are isolated Sandbox data, not Live payments or a fabricated success. Native macOS execution/cross-compilation boundaries and the unchanged SDK canonicalization/cache defects are recorded in the documentation evidence.
Full guide: https://licensing.kdpika.com/docs/v1/sdks/sample-apps
Common demonstration flow
- Start fresh and check. Expected: NOT_ACTIVATED or a friendly refusal; token-presence status alone never enables a feature.
- Enter a wrong email for the genuine Sandbox key. Expected: INVALID_LICENSE and no feature access.
- Activate with matching data. Expected: real signature/binding/policy acceptance or a documented safe failure.
- Restart/check with the same state. Expected: stable identity and eligible cache or online verification.
- Validate online, then inject only a transport outage in an isolated test. Expected: bounded accepted signed state or honest refusal according to that actual SDK/client.
- Inject an explicit HTTP refusal. Expected: no stale offline permission, regardless of earlier true features.
- Use the protected PDF demo. Expected: validity/signature/feature gate; PHP/WPF recheck on the server/controller action. No real payment, invoice or PDF is generated.
- Deactivate. Expected: confirmed release, cleared token/cache and no feature grant.
Storage, UI and deployment safety
Electron owns the SDK in its main process and checks the IPC sender/frame; context isolation and sandboxing stay enabled. Renderer code receives only safe decisions. PHP owns the SDK on the server and protects state-changing forms with actual session/CSRF checks. Its access code is for local testing, not a production login design.
Serialize one installation state writer, keep identity stable and store state outside the app installation/ASAR/public web tree. File permissions are not automatically an OS vault. Do not package test secrets, arbitrary-path IPC, a test-only clock or a populated cache. The exact README explains each runtime/platform requirement.
A visible button is never authorization. Recheck valuable server-side actions through your application auth/tenant/security layer. An attacker controlling a local app can patch it; do not promise unbreakable desktop protection.
Verified results and honest limits
The documentation evidence records actual source and packaged Electron windows, Python source/frozen CLI, PHP browser/CSRF workflow, C# controller/API tests and cross-build, and real Go/Java CLI runs. Local loopback forwarders deliberately inject outages/refusals; no production/provider outage, Live key or payment is used.
Automated native macOS runs do not establish Windows/Linux GUI execution, mobile vault behavior, notarization or formal accessibility/security certification. WPF is Windows-only and is handled under the explicit compile-plus-controller R18 boundary. Current SDK signing/cache incompatibilities stay disclosed; this documentation release does not fix them silently.
The recorded Electron dependency audit reports 8 moderate, 0 high and 0 critical development-tree findings, and 0 production-tree findings. The moderate advisory propagates through packaging dependencies; this is not a zero-vulnerability certification. Run npm audit before distributing your own build and review tested dependency updates. These development tools are not installed on the PHP hosting server.
Expected result
Your integration authenticates signed state and handles failures without granting features. Installation identity, source version and test boundaries remain explicit.
Common mistakes
- Running a local demo router as a public production identity provider.
- Shipping a populated cache, customer key or developer API key.
- Treating UI button state or release success as permission.
Security notes
Keep developer keys on trusted backends, pin independent key trust, preserve HTTPS/signature verification and never equate token presence with permission. Local machine owners can patch software; a successful build or checksum is not an anti-tamper certification.
Troubleshooting
| Symptom | Cause | Action |
|---|---|---|
| App starts but no activation | Missing App ID/state configuration | Follow the exact project README and use real Sandbox values |
| C# offline refuses | Known real Unicode cache limitation | Show the refusal/online recovery; never bypass signatures |
| App update creates another installation | State stored in an ephemeral installation/extraction path | Use a stable private per-application state root |
Next steps
Review the SDK downloads, test vectors and API errors for the exact selected client.