What you will try
You will make a real Sandbox license and export a real CSV with PHP. 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 example uses the official PHP SDK 2.0.1 directly. It verifies signed access and the csv_export feature before writing the file. The local Python launcher only collects your test configuration; it is not the licensing engine for this example.
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 64-bit PHP 8.2+, cURL and Composer first. The launcher/setup helpers use Python 3.11–3.14 once; it is not an extra dependency of the official PHP 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 php
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 php
- 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 php --release
The helper runs the fixed local command php app.php from the php folder. The example is command-line code, not a packaged desktop GUI or public web login system. For your own UI, call the same SDK guard immediately before protected work.
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 |
| Operation | SDK calls / checks |
|---|---|
| Standard guard | $result = $client->check(); then $result->valid, $result->signatureValid, $result->feature("csv_export") |
| Shared seats | $client->checkout(), heartbeat(), checkin(), close(); call tick() during long-running work |
| Credits | $client->consume(1, "your-stable-job-key"); $client->getBalance() |
The first native example deliberately refuses credit plans because it does not include a durable charge/job journal. It must never offer a free metered export. Study the complete credit job example for retry/work deduplication, then implement the same job rules around your own SDK calls. The table names methods; it is not a complete credit implementation.
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.