What you will try
You will make a real Sandbox license and export a real CSV with Java. First follow the small dashboard fragments below, then run the prepared example. You don't need to write a full app to see the first result.
This is a learning launcher, not a native Java SDK. Your Java file starts the included local Python SDK helper. Python verifies the license and performs the actual protected CSV export. This gives you an easy real test without pretending that a REST transport sample alone provides native fingerprinting or all SDK features. For a completely native production integration, follow the REST client requirements.
1. Pick Sandbox
Open your dashboard. At the top choose Environment → Sandbox. All files in this first-project bundle deliberately use Sandbox; they cannot be switched to Live just by changing a browser selection.
Work in test mode
SandboxChoose Sandbox before creating tutorial licenses.
This changes the dashboard view. The application example also explicitly uses SANDBOX; it does not read your browser choice.
2. Create a product for the test
Open Products → New product. Use an example name such as Orbit Notes and the values below. Choose Desktop for a computer/CLI app; choose Web if this will be a trusted backend installation. Create it and copy your actual App ID from its card.
What are you licensing?
SandboxUse a separate test product. The name and App ID shown here are examples, not real account data.
Orbit Notes
SandboxCopy the actual App ID from your own product.
app_YOUR_PUBLIC_IDApp ID is public. Never paste a management API key into a desktop app or browser.
3. Give the test customer CSV export
Open Plans & features → New plan. Choose your product. Enter a name/slug, Max devices = 2, Duration days = 30, Feature keys = csv_export. Leave shared seats blank and credits off for the first run. Choose Create plan.
Define access and entitlements
SandboxThe 2-device allowance belongs to each customer license. It is different from the workspace device allowance.
Open Licenses → Create license. Choose that product/plan, enter an email you control and create the license. This also creates or reuses that customer, so a separate customer-creation step is not required. Copy the key privately.
Grant product access
SandboxThis license will be isolated in SANDBOX.
The dashboard creates or reuses the customer for the entered email. You do not need a separate Add customer step.
4. Download and prepare the example
Download the first-project files. Extract them to a private local folder and open your terminal there. Install JDK 17+ with the java source-file launcher first. The launcher/setup helpers use Python 3.11–3.14 once; it is not an extra dependency of the official Java SDK itself.
Create a private environment:
python -m venv .venv
Activate it: Windows PowerShell uses .venv\Scripts\Activate.ps1; macOS/Linux uses source .venv/bin/activate. Then prepare only your language:
python prepare.py java
Preparation installs/builds the selected example only. It does not create an account, activate a license or grant credits. Package downloads use the current SDK and reviewed local package checksums where applicable. If installation fails, read its runtime/package message; do not disable signature or checksum checks.
5. Run and answer three simple questions
python launch.py java
- Paste your real public App ID from Products.
- Enter the Sandbox license privately when asked. It is not written into source files or command arguments.
- Enter its matching customer email.
Expected result: the terminal prints Saved: and a path to export.csv. Open that file; it contains “My first licensed export”. A refusal leaves the protected export locked. Keep tokens/state in the private per-language folder under your user profile, not in a public web folder.
On later runs leave the key empty to reuse saved activation. Each language example has its own installation state and therefore uses a separate device allowance. Before switching languages on a small plan, release the old example machine:
python launch.py java --release
The native launcher forwards control to bridge.py; it does not trust an unsigned HTTP permission response. The protected work stays inside the local SDK process. The helper and Python interpreter would need to be packaged and protected with your real application; this tutorial is not a completed native app installer.
6. Add one advanced rule at a time
The dashboard settings are the same in every language. Use the full visual feature walkthrough to see each exact section and button. The language-specific code names are below; they are not additional dashboard fields.
| You want | Dashboard choice | What your application must do |
|---|---|---|
| A computer allowance | Max devices on the software plan / Devices override | Check the server's signed result; do not invent a local device counter |
| Some offline use | Product → Validate every / Offline grace | Use SDK verified cache within signed deadlines; no instant offline revocation |
| Strict/flexible matching | Product → Device matching | SDK collects hashes automatically; never generate a random fallback |
| Shared running seats | Shared seats → Apps running at once and timing | Keep a signed lease alive and release it when the app closes |
| One credit per job | Usage credits; then grant units on the issued license | Confirm a signed consume with one stable key before the job; persist/reuse the job key on uncertainty |
| One customer's exception | License → Limits & overrides | Re-check; use effective signed settings instead of customer-specific hard-coded rules |
| Customer self-service | Customer portal → Copy link | Open the real publisher sign-in URL; do not put a license key/token in it |
| Your brand | Customer portal branding | Save name/logo/color/support email; hide platform branding only if included |
| Change history | Audit logs | Review eligible recorded actions; keep application logs free of secrets |
For this learning route, the Python helper already handles standard signed access and shared-seat lifecycle for a one-shot job. It refuses metered access; use the durable Python credit example to learn online charging. A fully native Java client still needs its own hardware collection, exact signature verification, private state, lease enforcement and idempotent credit/job flow. It is not supplied as a full SDK by this launcher.
7. Check your work
- Correct key, matching email, same product and Sandbox: one real CSV appears.
- No
csv_export: access is refused. To change existing grants, edit the plan and choose existing-license scope, then validate online. - Device allowance reached: release another example machine before a genuinely new activation. Do not delete state folders or copy activation tokens to simulate more computers.
- Shared seats full: wait for a seat to be released. A one-shot example releases its seat at exit; use separate long-running apps to test simultaneous usage.
- A credit plan: the first export route refuses unpaid work. Credits are online-only; a normal feature check does not consume units.
Before you put this on the internet or ship an installer
Keep secrets and private state off public web paths and out of source control. A desktop license check is not your SaaS user login; authenticate and authorize each real web customer on your backend. A browser cannot collect a supported native hardware fingerprint. Real OS/framework, packaging, process and credential-vault review is still required. Compilation or a helper smoke test does not certify a complete app.
All visual learning paths · Shared feature walkthrough · Current SDK capabilities.