--- title: "Rust: your first licensed export" description: "Follow small dashboard examples and run a protected CSV export with Rust; understand native SDK or helper-based boundaries." slug: "/docs/v1/tutorials/rust" section: "Practical tutorials" order: 1102 audience: "all" level: "beginner" last_updated: "2026-10-26" version: "v1" related: ["/docs/v1/tutorials", "/docs/v1/tutorials/python", "/docs/v1/sdks/capabilities"] draft: false layout: "guide" --- ## What you will try You will make a real Sandbox license and export a real CSV with **Rust**. 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 Rust 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](/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. Dashboard example: Work in test mode Open: Dashboard header → Environment Example data only; use your own real dashboard. Environment: Sandbox 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](/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. Dashboard example: What are you licensing? Open: Products → New product Example data only; use your own real dashboard. Product name: Orbit Notes Slug: orbit-notes Description: A small app that exports a CSV file. Platform: Desktop License prefix: ORBT — 2–8 letters or numbers. Buttons: Create product Use a separate test product. The name and App ID shown here are examples, not real account data. Dashboard example: Orbit Notes Open: Products → Your product Example data only; use your own real dashboard. App ID: app_YOUR_PUBLIC_ID App 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](/plans) → **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**. Dashboard example: Define access and entitlements Open: Plans & features → New plan Example data only; use your own real dashboard. Product: Orbit Notes Plan name: Personal test Slug: personal-test Price: 0 — Reference metadata for this tutorial; creating a plan does not collect payment. Currency: EUR Billing type: One-time Duration days: 30 — This teaching license lasts 30 days from its start. Max devices: 2 Feature keys: csv_export Apps running at once: Leave blank — Blank means a normal license, not a floating one. Usage credits (pay per use): — Leave off for your first feature-based export. Buttons: Create plan The 2-device allowance belongs to each customer license. It is different from the workspace device allowance. Open [Licenses](/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. Dashboard example: Grant product access Open: Licenses → Create license Example data only; use your own real dashboard. Product and plan: Orbit Notes / Personal test Customer name: Jane Example Customer email: jane@example.com — Use an email you control in your actual test. Company: Leave blank (optional) External customer ID: Leave blank (optional) Buttons: Create license 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](/docs/downloads/kdpika-first-projects-1.0.0.zip). Extract them to a private local folder and open your terminal there. Install **Rust 1.90+ and Cargo** first. The launcher/setup helpers use Python 3.11–3.14 once; it is not an extra dependency of the official Rust SDK itself. Create a private environment: ```bash 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: ```bash python prepare.py rust ``` 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 ```bash python launch.py rust ``` 1. Paste your real public **App ID** from Products. 2. Enter the Sandbox license privately when asked. It is not written into source files or command arguments. 3. 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: ```bash python launch.py rust --release ``` The helper runs the fixed local command `cargo run --locked` from the `rust` 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](/docs/v1/tutorials/python) 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 | `client.check(); then result.valid(), result.signature_valid(), result.feature("csv_export")` | | Shared seats | `client.checkout(), heartbeat(), checkin(), close(); stop at signed lease expiry` | | Credits | `client.consume(1, Some("your-stable-job-key"), None); client.get_balance()` | 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](/docs/v1/tutorials/python/credits) 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. **Rust starter boundary:** its public result intentionally hides raw signed payloads. This simple starter makes an online balance-policy check to refuse metered plans before export. It is not an offline Rust app example. Use the SDK normal verified check/feature flow with a deliberate product model for real offline work. ## 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](/docs/v1/tutorials) · [Shared feature walkthrough](/docs/v1/tutorials/python) · [Current SDK capabilities](/docs/v1/sdks/capabilities).