--- title: "TypeScript: your first licensed export" description: "Follow small dashboard examples and run a protected CSV export with TypeScript; understand native SDK or helper-based boundaries." slug: "/docs/v1/tutorials/typescript" section: "Practical tutorials" order: 1104 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 **TypeScript**. 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 TypeScript SDK.** Your TypeScript 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](/docs/v1/sdks/build-your-own-client). ## 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 **Node.js 22+; local TypeScript/tsx installed by prepare.py** first. The launcher/setup helpers use Python 3.11–3.14 once; it is not an extra dependency of the official TypeScript 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 typescript ``` 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 typescript ``` 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 typescript --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](/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 | 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](/docs/v1/tutorials/python/credits) to learn online charging. A fully native TypeScript 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](/docs/v1/tutorials) · [Shared feature walkthrough](/docs/v1/tutorials/python) · [Current SDK capabilities](/docs/v1/sdks/capabilities).