Manual integration guide
First authorize one real operation, then add the capabilities your policy needs. This guide connects platform setup with the code in your app.
What to prepare
Prepare a working project, product ID, every signing public key for that product, a test license and the feature IDs to protect. Feature IDs are case-sensitive and must match the issued license.
Desktop apps, plugins and CLIs use the SDK locally. Web applications enforce licensing and protected operations on a trusted backend; the browser can display status but cannot authorize execution.
Connect the application lifecycle
- Install a pinned version
Choose a language under Client SDK and run its install command. Configure the product ID and complete key-ID/public-key map. Trust only the product keys you explicitly configure. Public keys can ship with the app; management API keys cannot.
- Let the customer paste the key
Provide an activation screen or interactive CLI. For the first test, copy the key from platform Quickstart and paste it into the integrated app. Production customers activate inside your app with the license key you provide to them. Never embed test keys in source, installers or logs.
- Start and restore licensing
Create one long-lived client using the startup example for your language. Supply the customer key initially; on later starts under the same user, leave it empty to restore private device credentials. Handle startup errors, offer retry and keep the UI responsive.
- Protect the actual operation
Use the language equivalent of RunFeature for ordinary features and RunMeteredFeature for configured meters. Put the real operation in the callback so denial prevents execution. Buttons, shortcuts, commands, background jobs and server routes must all pass through the same protected boundary.
- Show status and handle changes
Keep the client alive so the SDK can send policy heartbeats. Update the UI on status changes and offer an online refresh action. Network failures can use only offline authorization the SDK still considers valid. Stop protected work after an explicit denial while preserving existing user data.
- Separate shutdown from device transfer
Close the client on normal exit to stop background work and attempt to return floating seats; a device binding is retained. Call Deactivate only for an explicit customer-requested transfer or unbind, then close the client. Do not deactivate on every exit.
These names describe the operations. Use the SDK reference for each language’s exact spelling, asynchronous behavior and return types. Select your language before copying the startup example and operation snippets.
Installation and complete examples · Methods and parameters for all nine languages
Add the capabilities your policy uses
| Scenario | What to implement or verify |
|---|---|
| Device binding and transfers | Use the SDK machine identity and private cache; verify a copied cache does not authorize another machine. |
| Schwimmende Sitze | Acquire a seat online for each process start; test cleanup, full capacity, lease expiry and crash recovery. |
| Heartbeats and network loss | Heartbeat interval and offline allowance are separate. Disabling heartbeats does not grant permanent access; cache expiry is not the final license expiry. |
| Fully offline activation | Generate a request on the target machine, obtain its response online and import it back on that machine; the policy must allow this offline mode. |
| Funktionsmessung | Use a stable unique ID per real job and retain it for retries. Handle reservation, confirmation, cancellation and actual business outcomes after a crash. |
| Version restrictions and upgrades | Supply the actual AppVersion when restrictions apply; maintenance rules require that version to be published first. Refresh authorization online after an app upgrade. |
| Customer self-service and release | Associate a customer email, provide the portal link, accept temporary transfer codes when needed, and distinguish normal exit from explicit device release. |
| Order and management automation | Use management API keys only on your server. License issuance, renewal and webhook handling are separate from client authorization checks. |
Prepare keys and caches for release
Pin the complete trusted product key set in application configuration and review key updates during releases; never accept an unknown key just because an activation response supplies it. Keep credentials and caches private to the current user. Do not ship or share them, test keys or development bypasses.