---
title: "Current integration limitations"
description: "Read the source-confirmed SDK, signature, storage and retry limitations before integrating KDPika Licensing."
slug: "/docs/v1/integration-notes"
section: "Integration notes"
order: 3
audience: "all"
level: "intermediate"
last_updated: "2026-10-21"
version: "v1"
related: ["/docs/v1/documentation", "/docs/v1/components"]
draft: false
---
These 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](/docs/v1/start/glossary#license) was created.

## Prerequisites
- Use synthetic [Sandbox](/docs/v1/start/glossary#sandbox) data for integration testing.
- Keep [developer API keys](/docs/v1/start/glossary#developer-api-key) on trusted servers, not distributed client applications.

## Validity before features
Always require result.valid or Valid before reading any [feature](/docs/v1/start/glossary#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](https://pypi.org/project/kdpika-licensing/) with MIT-licensed [GitHub source](https://github.com/kdpika/kdpika-licensing). Use Python 3.11–3.14, import kdpika_licensing and follow the [current Python guide](/docs/v1/sdks/python). 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](/docs/v1/start/glossary#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](/docs/v1/start/glossary#activation) environment headers default to Sandbox. Developer API keys and [activation tokens](/docs/v1/start/glossary#activation-token) determine their own environment. [Products](/docs/v1/start/glossary#product) and [product plans](/docs/v1/start/glossary#product-plan) 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](/docs/v1/start/glossary#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](mailto:hi@kdpika.com). 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](/docs/v1/documentation) and contact [support](mailto:hi@kdpika.com) about a release blocked by these limitations.

## Related
- [Public security overview](/#security)
- [Privacy information](/legal/privacy)