Questions and answers

KDPika helps you issue software license keys, control access to features, manage installations and check whether a license is still valid. Your application calls the licensing API and uses its answer to allow or deny access.

The dashboard brings your products, customers, licenses, devices and activity into one workspace. You still build and distribute your own application.

Independent developers and software teams building desktop apps, web backends, services or command-line tools. It is useful when you need to manage paid features, trials, expiry dates or installation limits without writing the whole licensing backend yourself.

Yes. Free is a limited Sandbox evaluation, not a production plan for selling software. You can create a test product, issue a test license and try activation and validation before choosing a paid plan.

The pricing comparison above shows the current allowances. Free does not include Live licensing or outgoing webhooks.

First, verify your email using the code or secure link sent to your inbox. Then complete your account details. If you selected a paid plan, continue to checkout; paid access is enabled only after the server confirms payment with the payment provider.

Your selected plan and billing interval are kept through registration. A payment return page alone is not proof that your subscription is active.

Create a product and one of your product plans, add a test customer, then issue a Sandbox license. Your app sends the product App ID, license key, environment and a stable installation ID to the activation endpoint.

Use an official SDK or the REST examples, then check validation before enabling your licensed features. Start in Sandbox with synthetic customer data.

Free, Starter, Pro and Business are subscriptions to the KDPika platform. They determine the workspace features and allowances available to you.

Product plans are the licensing rules for your own software: features, expiry, trials and device limits. Your KDPika subscription is not a subscription purchased by one of your software customers.

Yes. Public documentation and the language examples on this page are available without an account. Workspace tools, API keys and account-specific downloads are available after sign-in.

Choose an eligible paid plan, switch the workspace to Live and issue Live customer licenses. Use Live credentials in your trusted backend and set your app to the Live licensing environment.

Products and product plans are shared configuration; customer and license records are environment-specific. Switching environments does not convert a Sandbox license into a Live license. Payment-provider Test/Live mode is a separate setting.

The integration examples cover Python, PHP, JavaScript, TypeScript, Java, C, C++, C#, Go, Rust, Ruby, Kotlin, Swift and Dart.

Rust, Python, PHP, JavaScript and C# have official SDKs. Rust is a Cargo source package; Python is also available on PyPI. The other languages use REST examples for the same API v1 contract; an example is not a full SDK. Check the documented runtime requirements before integrating.

You can integrate from any language that can make HTTPS requests and read JSON. Use the API v1 reference for activation, validation and deactivation.

If you implement offline access, you also need compatible Ed25519 verification, the documented canonical JSON format, trusted public keys, installation binding and deadline checks. Do not treat an unsigned cached JSON file as a valid license.

Yes, when your chosen language, runtime and HTTP/cryptography libraries support the target operating system. Licensing uses the same API contract on each platform.

Storage locations, file permissions, secure credential stores and application packaging differ by OS. Test your actual packaged application on every OS you support; the examples are not a certification of every framework or OS release.

For a web application, enforce paid access in your authenticated backend. A browser-only check can be bypassed and must not protect server resources on its own.

For desktop software, use the SDK or API in the trusted application process. JavaScript SDK usage targets Node.js or the Electron main process, not a browser bundle containing management secrets.

No. Public activation uses a product App ID, which is not a secret management credential. Secret developer API keys belong only in your trusted backend.

Keep keys scoped to the necessary environment, product and permissions. Do not ship them in desktop binaries, browser JavaScript, public repositories or customer screenshots.

Activation registers an installation against a license and returns an activation token with signed license data. Validation checks that activated license again and returns its current signed state.

Your app must check the result before using features. An HTTP response arriving successfully does not, by itself, mean the license is valid.

Use one of the five SDK sources when it fits your runtime. They handle signed license checks, machine binding, leases and usage credits through the same API. For another language, implement the documented REST contract and signature checks.

Check compatibility before installing: earlier published registry packages and ZIPs predate the server’s required fingerprint contract. The updated source APIs and those older artifacts are documented separately; do not assume the same version label proves compatibility.

The SDK guide explains Python 3.11–3.14, virtual environments, optional keyring/UI extras and installation. The published PyPI package is kdpika-licensing and the import is kdpika_licensing.

The current server needs a fingerprint-capable client. Published 1.1.6 predates that change. Use the guide’s current-source compatibility instructions; do not install the earlier package expecting the new API contract to work.

The Python SDK source is public on GitHub under the MIT license. You may use it in commercial applications subject to that license, including its copyright and permission notice requirements.

This covers the Python SDK, not the KDPika SaaS backend, platform access or other SDK packages. Never publish developer API keys, customer license keys or activation tokens in a repository.

Keep a backup of your private installation state, stop app processes and use an SDK that implements the current required fingerprint contract. Preserve the stable installation ID; do not copy an activation token to a second machine.

Test activation, signed checks and your chosen licensing model in Sandbox. An older cache is not proof of permission under a newer contract. Read the SDK compatibility notice before selecting a package.

Yes. Add an activation flow, store a stable installation ID and token safely, and check validation before unlocking restricted actions. Decide how your UI handles expiry, device limits and temporary connectivity problems.

Keep server-side protection for server resources. KDPika does not automatically rewrite, obfuscate, package or update your application.

Business lets you allocate usage units and atomically consume them before a billable operation. Save a unique idempotency key for the job; if the response is lost, retry with that same key to avoid a second deduction.

Credits require an internet connection. Insufficient balance returns INSUFFICIENT_CREDITS; do not perform the billable action. Deduplicate the actual job too. Allocating or returning credits does not charge or refund a bank payment.

Yes, on Pro and Business. Customers sign in to your portal using an emailed single-use link or a license key. They can see license status, expiry, machines, credit history and running shared-seat sessions.

They can deactivate a machine or end a stuck session within your configured allowance: initially 3 removals per customer/product in any 30 days. The portal does not sell, take payment, manage invoices or issue financial refunds.

Pro supports your display name, HTTPS logo, accent color and support email, with KDPika identification retained. Business can also hide KDPika branding in the portal and its sign-in emails.

Custom-domain hosting is not supported. The portal runs on the platform domain; changing its logo does not change the host.

Free is a basic test account. Starter supports ordinary Live licensing. Pro adds strict/flexible device-matching settings, floating licenses up to 10 simultaneous seats per license, and a customer portal.

Business includes all licensing features, with usage credits, full portal white label, audit log access, higher workspace limits and dedicated support. It has no commercial platform cap on floating seats. Your own software-plan limits still apply.

A regular license may work offline within its signed validation interval, grace window and expiry. A floating app can keep access only until its much shorter signed lease expires. It cannot reserve or renew a seat offline.

Usage-credit checks and consumption are online-only. No offline app can learn about a new revocation before reconnecting. Never extend the deadlines in saved JSON.

No. Signatures make forged or changed replies detectable when your app verifies them correctly. Tenant checks, machine binding and atomic seat/credit operations protect the server’s decisions.

An attacker with control over a client machine can modify application code or spoof local inputs. KDPika does not provide hardware attestation, automatic obfuscation, DRM certification or instant revocation on an offline machine.

No on-premise license server, custom-domain portal hosting, browser-only hardware fingerprinting or automatic application obfuscation is included. Your application enforces the licensed features.

The portal has no checkout or financial billing. Usage credits are units, not money. PHP long-running jobs must call tick() regularly to renew floating leases. Published SDK versions may precede the current source contract; check the compatibility guide.

Product plans can describe trial, monthly, yearly, one-time and lifetime licensing. A license may have an expiry date or no expiry date, depending on the rules you configure.

These are access rules, not automatic payment collection. Connect your own sales backend to issue or renew customer licenses after a confirmed purchase.

Yes. Define features on your software plans, then check them only after the license result is valid. A license-specific override takes precedence over the plan value.

A feature flag does not spend units. Business adds an explicit usage-credit ledger and consume operation for billable work. Credit consumption stays online and is separate from charging money.

The activation API accepts a customer email. When supplied, it must match the customer associated with that license; a different email is rejected.

Key-only activation is also supported. If your app requires an email, enforce that in your integration as well. Matching an email string is not proof that the user owns that inbox.

An installation has a saved random ID. Fingerprint-capable SDKs also collect product-salted hardware hashes, send those hashes to the server and verify the signed binding. Raw serials are not stored by the platform.

Basic binding works on every plan. Pro and Business let you configure strict or flexible matching. Hardware hashes can be spoofed by an attacker controlling the machine; this is not hardware attestation. Browser JavaScript fingerprinting is unsupported.

No. A device limit controls the number of active installations. An activation limit controls the cumulative activations allowed for that license.

Revalidating an active installation does not consume another activation. Deactivating a device releases its active seat, but does not reset the cumulative activation count.

A customer can deactivate the old installation through your app or a customer portal link you provide; you can also manage devices from the dashboard. The new installation must still fit the license’s device and cumulative activation limits.

Resetting devices releases active seats but does not reset cumulative activations. Explain your transfer policy to customers before they buy.

Yes, through the dashboard or the scoped management API, subject to the license’s current state. Suspension can be reversed for an otherwise eligible license; revocation is permanent in the current lifecycle.

Renewal can extend an eligible expiry, including an expired license, but cannot renew a revoked or cancelled license. After suspension and restoration, the app needs a fresh activation token.

Yes. Floating licensing counts running app sessions separately from registered devices. An app checks out a seat, renews its short-lived lease with heartbeats, and checks it in when finished. Unreachable sessions stop counting after their timeout.

Pro includes up to 10 simultaneous seats per software license. Business has no commercial platform seat cap; you still configure a positive per-license seat limit and device allowance. A full seat pool returns ALL_SEATS_IN_USE. No on-premise licensing server is included.

After successful online activation, a compatible SDK can use verified, signed cached license data within your configured validation and offline deadlines, and never beyond the license expiry.

A first activation needs the server. Offline access is a bounded fallback for connectivity problems, not an unlimited or air-gapped license.

Your product policy defines the validation interval and offline grace deadline. Choose values that balance customer connectivity with how quickly you need changes to reach the app.

The deadlines are measured from the signed server time. The offline grace period is not extra time automatically added after the next-validation deadline.

Not while the app is disconnected and still within a previously issued offline allowance. It learns the server’s decision when it reconnects, or loses offline access when the signed deadline or license expiry is reached.

A confirmed server rejection is not treated as a network failure and does not qualify for offline fallback. Shorter offline allowances reduce this delay.

Ed25519 signatures let your integration verify that license data was issued by the trusted server and has not been altered. The signed payload includes context used to check the product, environment, installation, status and deadlines.

A signature is not encryption. Never put confidential customer data or server secrets into a payload simply because it is signed.

Use a protected application-data location and, where appropriate, an OS credential store. Python supports an optional keyring; PHP, JavaScript and C# use permission-protected files unless you add another storage integration.

Do not put tokens in publicly readable files, browser bundles or logs. Test permissions and storage behaviour on each supported operating system.

No software licensing service can guarantee that. A user who fully controls a local machine may modify the application or bypass local checks.

Use licensing alongside server-side enforcement where possible, secure updates and appropriate application hardening. KDPika is not a substitute for those controls or an independent security audit.

Distinguish a connection problem from a server decision that a license is invalid. A verified cached license may allow temporary access only within its signed deadlines.

Show a helpful retry message, avoid rapid retry loops and preserve the request ID for support when available. Never grant paid access from an unchecked success flag or editable local cache.

API logs record request IDs, endpoints, status codes and timing; the API logger does not capture request bodies or Authorization headers. Installation identifiers are hashed for device records, and optional labels, platform and app versions can be recorded.

Customer emails, identifiers and metadata can still be personal data. Minimise what you send and consult the privacy information for retention and processing details.

Current platform plans are priced in EUR. Monthly billing charges each month. Annual billing charges the full annual amount at once, not the displayed monthly equivalent each month.

The pricing cards show the annual total and calculate savings against twelve monthly payments. Your final checkout summary confirms the amount before you pay.

Compare products, active customer licenses, API requests, webhooks, log retention and support in the table above. Use the active-license slider as a starting point, then check the other allowances too.

Plan names and allowances come from the current catalog. A recommendation based on license count is not a guarantee that every other part of your workload fits.

Product, active-license and webhook creation have plan limits. Monthly API usage is currently monitored with warnings, rather than a hard monthly cut-off. Displayed workspace device and member allowances are not separate activation gates.

Existing customer licenses are not automatically revoked just because a workspace reaches a quota. Per-license device and cumulative activation rules are separate and are enforced.

Platform checkout uses Stripe or Mollie, depending on the payment gateway enabled for the platform. Available payment methods are shown at checkout; some bank authentication steps may open a provider or bank page.

Card fields are handled by the payment provider, not stored as card numbers or CVCs by KDPika. KDPika retains billing references and payment status needed to manage your subscription.

Eligible subscriptions can schedule a change from Billing & usage inside KDPika. The review screen shows the new plan, price and effective date before you confirm.

Current supported changes are scheduled for the end of the paid period, not an instant prorated upgrade. New paid access follows confirmed renewal payment. If a change is unavailable, Billing explains the reason; cancellation remains a separate action.

Open Billing & usage and choose “Cancel subscription” in subscription management. Review and confirm the cancellation; no support conversation is required for an available self-service cancellation.

Cancelling renewal keeps your current paid plan until the displayed period-end date. It is not an automatic refund, does not cancel an already outstanding invoice and does not immediately delete your account.

Billing & usage shows your billing history and available invoice downloads. When an original provider PDF is available, use it; a local printable view is a separate presentation and does not change an issued provider document.

Refund eligibility depends on the cancellation and refund policy and applicable rights. Contact hi@kdpika.com with the relevant invoice; a refund request is not a confirmed refund.

Follow the action shown in Billing or checkout, such as retrying payment or completing bank authentication. Paid features are not activated just because you return to a success URL.

If no payment action is available, please contact support at hi@kdpika.com. Do not create repeated purchases to try to force activation. Test-mode payments are labelled and do not represent a real-money purchase.

KDPika’s current sales terms state the French VAT-exemption regime: “TVA non applicable, article 293 B du CGI”. No VAT is collected under that regime.

Check the final checkout total and invoice. If the applicable tax treatment changes, the amount and required tax information must be shown before you confirm a purchase.

If your checkout offers a promotion-code field, enter the code there and check the updated total before confirming. Availability and eligibility depend on the payment gateway and the promotion; not every checkout supports the same options.

Check how long the discount applies. A discount on your first payment does not necessarily reduce future renewals.

The paid platform entitlement ends on the date shown in Billing. Free is a restricted Sandbox evaluation, not a replacement production tier for continued Live license issuance.

Resource creation and existing customer-license validation are separate: reaching Free limits does not itself revoke your issued licenses. Your own license expiry and status rules still apply. Plan your transition before cancelling if you serve real customers.

When the subscription is still eligible, Billing offers the option to resume renewal before the current period ends. Review the updated renewal details before confirming.

Once a subscription has ended, you may need a new checkout instead of resuming it. If Billing does not offer a suitable action, contact hi@kdpika.com.

No. The platform’s Stripe and Mollie integrations manage your KDPika subscription. Selling your own software remains a separate flow with your own store, checkout or payment provider.

Your trusted backend can use the license-management API to issue or renew licenses after it independently confirms a customer payment. KDPika does not automatically fulfil every third-party store purchase.

Yes. Call the scoped management API from your trusted backend after confirming the sale. Keep your payment and licensing records associated so that renewals, refunds and access changes follow your own business policy.

Do not create licenses solely from a browser redirect or expose a management API key in a checkout page. Use the API reference for the supported operations and request contract.

Paid plans with a webhook allowance can configure outgoing endpoints for supported license and device events. Deliveries are signed and have scheduled retries and delivery history.

Verify the signature, handle duplicate deliveries safely and use the documented event names and payloads. Repeated delivery must not create a second order or grant a second entitlement.

No. KDPika handles its own license checks and delivery history. Your integration can send events to an HTTPS endpoint on your own backend.

An optional third-party request catcher is a debugging tool, not a dependency. Do not send real customer information or secrets to an untrusted testing endpoint.

No. A customer activates your application using the license flow you build. They do not need a developer workspace to use a license issued by you.

On Pro and Business, customers can use your portal sign-in page with an email link or license key. Email links work once for 15 minutes and open a session of up to two hours. Device removals follow your configured allowance.

You, as the software publisher, manage your product’s licenses, transfer rules and sales policy. Customers should contact you about your application or a purchase made from you.

KDPika support handles the platform and your KDPika subscription; it does not replace the publisher’s customer support or automatically refund purchases from the publisher’s store.

The workspace includes API logs, audit logs and webhook delivery history with relevant status and request context. Retention depends on your platform plan and the type of record.

Use request IDs to investigate without sharing secret keys or full tokens. Keep your own application-side diagnostics for behaviour that occurs entirely on a customer’s device.

Not every setting is automatically retroactive. In particular, device and cumulative activation limits are copied when a license is issued; changing those plan values does not update that existing copy.

Review the affected license and test the intended change in Sandbox. An offline app also cannot learn about server-side changes until it reconnects or its signed allowance ends.

Only the information needed to manage your licenses and support your customers. Avoid sensitive personal data in free-form metadata, device labels or support messages.

You are responsible for how you collect your customers’ data and for explaining your licensing checks in your own privacy notice. Review the platform privacy notice and DPA for the respective roles.

The platform provides account-data exports and workflows for access, correction, erasure and other privacy requests. Exports exclude passwords and secret credentials.

Deletion is not an instant purge of every record: some records can remain for billing, security or legal obligations. Contact hi@kdpika.com if you need help with a specific request.

No. Privacy tools, data-processing terms and engineering controls support your work, but they are not a universal compliance certification.

Your own data collection, legal basis, customer notices, retention and integrations still need to match your business. Do not assume all data or provider support access is EU-only without reviewing the current provider information.

The cookie controls let you accept or reject optional categories and change your choice later. Necessary storage supports functions such as sign-in and security.

The cookie page describes the services and storage in use. Payment-provider storage can be involved when you deliberately enter checkout; it is not a reason to enable unrelated analytics.

Check your spam folder and confirm that you entered the correct address. Use the latest message and request another only when the resend option becomes available.

Verification and reset links expire and cannot be reused indefinitely. If you are still blocked, contact hi@kdpika.com; never send us your password or verification code.

The public status page shows recorded health checks, uptime history and incidents. It describes observed service health, not a guarantee that every customer’s network is working or a contractual uptime SLA.

Because it is hosted alongside the platform, a complete hosting outage can also make the status page unavailable. Your app should still handle timeouts and its configured offline policy.

Use the documentation, your workspace support area or hi@kdpika.com. The pricing comparison shows the support level associated with each plan.

A support-level label is not a guaranteed response time or a 24/7 service-level agreement. For an integration issue, include your language, runtime, environment and a request ID, but remove secrets and unnecessary personal data.

Sales terms, service terms, cancellation and refund information, privacy, cookies and data-processing terms are publicly available from the footer. Read the checkout summary and applicable terms before confirming a paid subscription.

If an important requirement is unclear, ask hi@kdpika.com before buying. Do not rely on an example or marketing summary as a replacement for the published terms.