Build licensed apps with Python

You will build Orbit Notes, a small app with a CSV export button. First give one test customer access. Then choose only the extra rules your app needs.

Read → copy the example choices into your real dashboard → save → try the app. The dashboard fragments below are HTML/CSS illustrations with example data. They do not change your account. Open the real page with the link in each step.

Before you start: three names, one simple difference

• Product: your app. Orbit Notes has one public App ID.
• Software plan: what one customer gets. Our first plan allows 2 computers and CSV export.
• Your KDPika plan: what your developer workspace may use. Advanced features depend on the capabilities enabled for it.

Do not enable every advanced option at once. Finish steps 1–4 first. You need Python 3.11–3.14, a KDPika account and an email you control. No card details or developer management key go into the example app.

1. Switch to Sandbox

Why: you can try licenses without mixing them with real sales.

1. Open your workspace.
2. At the top, open Environment and select Sandbox.
3. Keep this choice while issuing all tutorial licenses.

Done when: the real header says Sandbox. Your Python example must also use KDP_ENVIRONMENT=SANDBOX; the dashboard cannot change a running app's environment for you.

2. Create the app you will license

Why: the App ID tells the SDK which software it belongs to.

1. Open Products and choose New product. On an empty page, use Create first product.
2. Type Orbit Notes. Use the example slug and prefix below, and choose Desktop. For the separate web example, choose Web instead.
3. Choose Create product. Copy its actual App ID from the resulting product card.

Done when: you have a real app_... ID copied from your account. The placeholder shown here is not a usable App ID. An App ID is public; a management API key is private and is not needed for this project.

3. Make a simple customer plan

Why: this tells KDPika what your customer is allowed to use.

1. Open Plans & features → New plan. Saving the new product may already open this form.
2. Choose Orbit Notes, name the plan Personal test, and enter its slug.
3. Use Max devices = 2, Duration days = 30, and Feature keys = csv_export.
4. Leave Apps running at once empty and Usage credits (pay per use) unchecked.
5. Choose Create plan.

What these choices mean: one customer's key works on at most two active computers, lasts 30 days, and includes CSV export. The plan price is reference data, not a payment being collected. Creating this record does not subscribe or charge anyone.

Done when: the plan appears under Orbit Notes. You can add stricter rules later; don't start with a credit/floating plan before the first standard export works.

4. Give one test customer a key

Why: your app needs a real customer license to activate.

1. Open Licenses, check that you are still in Sandbox, then choose Create license.
2. Choose Orbit Notes / Personal test. Enter an email you control and an example customer name.
3. Leave Company and External customer ID empty if not needed. Choose Create license.
4. Privately copy the newly created key. The dashboard creates or reuses the customer for that email automatically.

Done when: you have three things: the public App ID, a Sandbox license key and its matching customer email. Do not put a key in a URL, screenshot shared with others or public source repository.

5. Run your first app and export a file

Download the Python projects and extract the ZIP. The project README lists setup commands for Windows/macOS/Linux. Choose your first app:

• Desktop window: install, activate and export step by step.
• Local web app: start a Python server and download a protected file.

You do not need to package a macOS/Windows installer to learn. Run the .py example first. Put your actual public App ID in its environment setting, run the file and enter the license and matching email when asked.

The standard example protects its real CSV export like this:

result = client.check()
if not result.valid or not result.signature_valid:
    stop_export()
if result.feature("csv_export"):
    create_the_csv_file()
# stop_export/create_the_csv_file are names in your own app.
# The downloadable example implements the actual file operation.

Done when: you open the exported CSV and see your message. A successful request alone is not access; the SDK verifies the signed result and the feature before the work.

6. Allow a customer to use the app offline

Use this when: a normal desktop app should keep working during a short connection outage. Skip it if every protected action needs your server.

1. Open Products, find Orbit Notes, and expand Validation & device policy.
2. For this test set Validate every (hours) = 24 and Offline grace (hours) = 168.
3. Choose Save policy. In the app, choose Check now to fetch the latest policy online.
4. After one successful online check, disconnect and try a normal CSV export within the allowed window.

What changes in Python: keep using client.check(). It decides whether an authentic saved result is still usable. client.validate() forces an online check. You do not write your own timer or extend the signed deadline.

Remember: 168 hours is 7 days, never beyond license expiry. Offline revocation is learned after reconnecting. Floating seats end at their shorter lease deadline; usage credits have no offline fallback.

7. Choose how strictly to match a computer

Use this when: you want to make copying local activation files to a different machine less useful, or choose how much hardware change to tolerate.

1. In the same Validation & device policy section, choose Strict or Flexible under Device matching.
2. To try Strict, choose the exact option below, then Save policy.
3. To allow some non-critical component changes, choose Flexible and set Matching components (flexible mode), for example 2.
4. Choose Check now while online and test on your actual target machine.

What changes in Python: nothing new is collected by your code. The SDK derives product-salted hardware hashes automatically and verifies the signed binding. Basic binding is always required; advanced policy settings require an eligible KDPika capability.

Flexible matching still protects saved motherboard/CPU anchors when available. It is not permission to move the same token anywhere. A VM hint alone does not reject access. If hardware is unavailable or mismatched, keep access locked; never replace it with a random fallback fingerprint.

8. Let many computers share fewer running seats

Use this when: a team may install the app on 10 computers but only 2 people should run it at once.

1. Create a separate software plan, such as Team seats, for Orbit Notes. Keep csv_export enabled.
2. Set Max devices = 10. In Shared seats (optional), set Apps running at once = 2.
3. Use Check interval = 180 and Release an unreachable app after = 600 seconds, then create the plan.
4. Issue a new Sandbox license for it and try it on separate real installations.

What changes in Python: the current SDK automatically checks out a seat after a successful activation/check and renews it in the background. Keep checking before protected work. Call client.close() when your app closes; the downloadable desktop example already does that.

Done when: the first two running installations may use their permitted feature and a further one cannot obtain a new seat. Close one app and retry. A crash releases its seat after the timeout, not instantly. A closed app remains an activated machine until it is deactivated.

See the short explicit checkout/close example. If the capability is unavailable in your workspace plan, this configuration is disabled; do not try to bypass it in code.

9. Charge one credit for each export

Use this when: your customer's access is based on completed jobs, not unlimited feature use. Credits are usage units, not money.

1. Create another software plan named Export credits. Enable Usage credits (pay per use). Leave shared seats empty while learning.
2. Issue its new Sandbox license. New credit licenses start at zero.
3. On that license's Manage menu, choose Usage credits. Select Add credits, enter 3 and save.
4. Run the durable credit export example with one stable job name.

What changes in Python: client.consume(1, idempotency_key=the_same_job_key) must confirm the signed charge before that job runs. The downloaded credit_export.py keeps the job key in SQLite and writes a real CSV.

Run the identical completed job again: the same output is returned without another debit. After a lost reply, retry the same job/key and message. A new key for the same uncertain job could charge twice. The final successful charge may leave zero and still authorizes that paid operation.

Done when: the balance changes from 3 to 2 for the first job, then stays at 2 when that same completed job is reopened. The SDK deduplicates the charge; your application also needs to deduplicate its actual work. The example implements that for its CSV, not arbitrary external payments or emails.

10. Give one customer an extra device or feature

Use this when: the plan normally allows 2 devices, but Jane should get 3 without changing everyone else.

1. Open Licenses, find Jane's license, and use Manage → Limits & overrides.
2. At Devices, choose Set for this license and enter 3.
3. Add an optional reason, then choose Save overrides.
4. To remove the personal exception later, use Reset to plan default for that field and save.

The same editor can adjust total activations, shared seats, expiry and extra features when allowed. Max devices counts active installations; total activations counts first activations/reactivations over the license lifetime. Deactivation does not reset the cumulative total.

What changes in Python: no customer-specific if customer == ... code. The SDK uses the server's effective signed limits/features. Reconnect and choose Check now for a new result; old valid offline caches cannot learn the change instantly.

11. Change the default for a whole plan

Use this when: a whole offer changes, such as raising the normal device allowance from 2 to 3.

1. Open Plans & features and choose Edit on the right plan.
2. Set Devices = 3. Choose New licenses only to leave current customers alone, or the existing-license option below to update current grants too.
3. Choose Review changes, inspect the affected-license count and warnings, then save the reviewed change. Individual overrides are kept.

To change a feature on the Edit screen, edit Plan features as JSON, such as {"csv_export": true}. This is different from the comma-separated Feature keys used on the New plan form. Setting false disables an entitlement; your app and plan must use the exact same feature key.

Important: plan changes can apply across Live and Test because the plan is shared. Use a separate tutorial product. Lowering a limit preserves existing active connections but blocks additional ones while usage is above the new limit. Prices/payment schedules are not rewritten by editing access settings.

12. Let customers help themselves

Use this when: customers should review expiry, see their machines or free a genuinely stuck shared seat without asking you every time.

1. Open Customer portal.
2. Copy Customer sign-in page (Live). For this Sandbox test, append ?environment=SANDBOX to the copied URL.
3. Open it and use the customer's email or license key. The actual portal verifies access; do not build your own token URL.
4. Put that publisher sign-in link in your app's Help menu. It is a normal sign-in URL, not a reusable secret login token.

What changes in Python: use webbrowser.open(portal_url) with the real public sign-in URL from your account. No separate portal SDK is required. Email sign-in may show this customer's authorized licenses; key sign-in opens only its own license. The portal can show balances/history and active shared sessions. It does not sell plans, collect payments, issue invoices or refund money.

13. Make the portal match your brand

1. In the same page, enter Display name, your HTTPS Logo URL, Accent color and Support email.
2. If your platform plan includes it, select Hide KDPika branding in the customer portal and self-service sign-in email.
3. Set the allowed Removals per customer, per product, in any 30 days, then choose Save portal settings.

Why the removal limit matters: deactivating machines and ending stuck sessions share one customer/product allowance. Set 0 if customers should contact you instead. The example value 3 allows limited self-service without unlimited cycling. Full white label does not add a custom-domain host or remove all signs of the actual platform domain.

14. Release an old computer safely

1. Open the license's Limits & overrides and find Machines on this license.
2. Choose Deactivate to release the machine's access, or Remove to release/hide it while preserving history.
3. Read and confirm the action. Use license suspension/revocation if the whole key should stop working.

What the app sees: new checks using revoked device tokens are refused and activation is needed again. A valid key might reactivate if limits permit; removing one machine is not a permanent hardware ban. An offline app learns about the server-side change when it reconnects or reaches its signed deadline.

15. Understand workspace limits without putting them in code

Open Billing & usage. These example figures show a Business-style allowance; your administrator may configure different values.

• Products: apps you manage, each with an App ID. It is not the number of features in your Python app.
• Active licenses: customer grants in the workspace, not devices or running sessions.
• API requests / month: the workspace allowance. Usage warnings do not automatically block requests. Let check() use a valid cache; don't force online checks for every keystroke.
• Active devices: workspace planning allowance; the customer's own software-license device limit is enforced separately.
• Live + Sandbox: separate test/real license data. A Sandbox key does not become Live by changing a label.
• Log retention: how long eligible server logs are retained. It does not extend license expiry or offline access.
• Support: the service level of your platform account; dedicated support is not a promise of instant response.

Do not copy 100, 100,000, 5M, 250,000 or 365 into Python constants. Configure the actual license policy and use the SDK's verified result.

16. See who changed access

Open Audit logs if your KDPika plan includes audit access. Look for the recorded plan/override/credit changes you just performed.

This is the platform's history of eligible actions, subject to retention. It does not record every export or button in your own application. If you need that, add your own application event log without keys, tokens, emails or raw hardware identifiers.

17. Move to Live only after your tests work

1. Finish the standard export, offline/lease/credit cases you actually intend to ship, and test on your target Windows/macOS/Linux machine.
2. Use a platform plan that includes Live licensing. Switch your dashboard Environment to Live and issue real customer licenses there.
3. Change your packaged app's environment to LIVE with a deliberate release configuration. Keep the same product's real public App ID and a separate private Live state.
4. Test your real store/email/renewal process. Do not distribute tutorial keys or copy your local activation directory into an installer.

Your next small step

Open the desktop instructions or the local web instructions. The files already implement the standard protected export; you only supply your App ID and your own Sandbox license. Then add one advanced model from the steps above.

Download project files · All language learning paths · Python API reference.