Developer data protection responsibilities

Collect only customer information needed for licensing and document how your application and KDPika handle it.

What you will learn

• Identify stored and signed customer/device data.
• Use export and privacy-request workflows accurately.
• Separate confirmed controls from unresolved provider/legal facts.

Prerequisites

• Read the public privacy notice and DPA.
• Know what customer information your own store/application sends.
• Review your intended legal roles with qualified advice.

Customer and device information

The licensing API logger does not store request bodies or Authorization values. That is not a promise that no other application, hosting or provider log exists. Hashing an identifier is pseudonymisation in many contexts, not automatic anonymisation. See CNIL's guidance on identifying personal data.

Data roles and notices

Your store and application determine what buyer data you collect and why. Review whether you act as controller and when KDPika acts as processor for customer licensing data; the operator also has separate account/billing responsibilities. Do not copy a generic role label without checking your actual arrangement.

Document purpose, data categories, recipients, retention, rights handling, security and international transfers where applicable. Keep the public DPA/subprocessor/legal texts under review; their publication is not a compliance certification or legal approval.

Export

1. Sign in to the intended workspace and open Settings.
2. Request the account/data export through the available export action.
3. Save it in restricted storage.
4. Confirm the organization, members, subscription, products, customers, masked licenses, invoices, support tickets and privacy requests belong to that workspace.
5. Remove the local copy when your justified use ends.

Expected result: tenant-scoped export, excluding password hashes, API secrets and signing keys. It is not an export of every possible backup, log or third-party provider record.

Rights requests and deletion

The workflow accepts access, rectification, erasure, restriction, portability and objection requests. Details are limited to5000 characters; the stored workflow target is30 days. That target does not prove every request is automatically fulfilled or replace legal deadline assessment.

Account closure soft-deletes the organization/user and anonymizes user display information. It does not comprehensively erase every related customer, license, financial row, backup or provider record. Do not promise immediate complete erasure after clicking close.

1. Identify the requester and the relevant workspace/customer proportionately.
2. Record the request through the supported privacy workflow.
3. Review the data and applicable retention/legal exceptions.
4. Coordinate required changes with support at hi@kdpika.com.
5. Document what was completed, retained with a reason, or requires provider action.

Expected result: a traceable human-reviewed response, not an invented automated deletion capability.

Retention and providers

API/audit retention follows platform-plan configuration. Delivered mail/webhook records have a30-day cleanup rule; other tokens and registration/idempotency records have their own expiry cleanup. Actual cleanup depends on scheduled jobs. A configured rule is not proof a production cron job ran.

The code supports Hostinger-compatible hosting, Stripe/Mollie platform billing and SMTP profiles for Hostinger/Titan, Brevo and custom SMTP. Source alone does not confirm the actual hosting contracting entity, data-centre region, support-access countries, selected production SMTP profile, signed DPAs or transfer safeguards. France is the operator's country, not proof all processing remains in France or the EU.

Confirm actual providers and contracts before promising EU-only processing. Review subprocessor information and ask support for unresolved operational facts. No SOC 2, ISO 27001, independent audit, response-time SLA or complete GDPR certification is claimed.

Application checklist

1. Send only needed customer fields.
2. Avoid raw IDs/tokens in public logs and screenshots.
3. Keep local signed caches private because they contain customer data.
4. Explain installation binding and offline behavior in your own notice.
5. Test export and rights workflows with synthetic data.
6. Maintain your own store/application retention and breach-response process.

Expected result: customer data protection is part of your integration design, not delegated to a licensing signature.

Expected result

You can explain which data is processed, what export/deletion actually does and which provider facts still require confirmation.

Common mistakes

• Calling hashed device IDs anonymous.
• Treating account closure as comprehensive erasure.
• Claiming France-based operation guarantees EU-only data hosting.

Security notes

Legal obligations depend on your processing and jurisdiction. This technical description is not legal advice. Never send private keys, payment-card details or unrelated sensitive records to support.

Troubleshooting

Next steps

Read signed responses and the threat model, then validate your own integration in Sandbox.

Related

• Verification examples
• Offline mode
• Security and disclosure