Using the Lyrinox License SDK

The Lyrinox License SDK is the small client layer your product uses to ask Lyrinox Market whether a customer is allowed to run your software.

The SDK is intentionally thin. Your product calls a native-feeling client in its own language. The SDK sends the request to Lyrinox Market. Lyrinox Market decides whether the license, account authorization, product ID, seller tag, activation state, subscription state, and product keys are valid.

That keeps the real licensing rules on the server, where they can be patched, audited, throttled, and improved without asking every seller to ship a new licensing engine.

Before you start

You need three things:

An approved seller account with API access.
A product with licensing enabled.
An API key authorized for license operations.

Apply for API access from API Keys. Download your account-bound SDK from Lyrinox License SDK.

Two validation models

Direct license validation

Direct validation is for products that ask the buyer for a license key.

Use this for desktop apps, plugins, server modules, templates with update checks, command-line tools, and most one-time purchase software.

The product sends:

license_key
product_id
seller_tag
API key
optional domain/device identifier for activation

The API returns whether the license is valid, active, expired, suspended, revoked, or out of activations.

Account authorization

Account authorization is for products that ask the buyer to connect their Lyrinox Market account.

Use this when you want the buyer to sign in instead of typing a license key, especially for subscriptions or software where account ownership matters more than a copied key.

The flow is:

start an account authorization request;
send the buyer to Lyrinox Market to approve access;
poll or validate the authorization from your product;
allow the product to run only after Lyrinox confirms access.

What the SDK sends

Native SDK requests include the same core fields across languages:

Field	Purpose
`product_id`	Identifies which Lyrinox Market product is being validated. Required.
`license_key`	The buyer's license key for direct license validation.
`seller_tag`	Your account-bound SDK build tag. Lyrinox uses it for ownership and abuse tracking.
`sdk_client_kind`	`sdk` for native SDK calls, `integration` when a platform integration relays the request.
`domain`	Domain, device, or install identifier for activation and deactivation.

Platform integrations add integration context, such as integration name, platform instance, and integration user tag. Native SDK calls do not need those fields.

What the SDK returns

The SDK returns structured results. Exact method names differ by language, but the meaning is consistent.

Validate

Use validate when you need a simple yes/no answer.

Successful response:

{
  "success": true,
  "valid": true,
  "status": "active",
  "product_id": 123
}

Common unsuccessful responses:

{
  "success": true,
  "valid": false,
  "status": "revoked"
}

{
  "success": false,
  "error": "License not found.",
  "code": "NOT_FOUND"
}

Check

Use check when you need license details for a settings screen, support view, or diagnostics panel.

{
  "success": true,
  "license_key": "lmlic_...",
  "status": "active",
  "active": true,
  "current_activations": 1,
  "max_activations": 3,
  "expires_at": null
}

Activate

Use activate when the product is being installed or first run on a domain/device.

{
  "success": true,
  "activations": 1,
  "max_activations": 3
}

If the buyer has used all activations, the response explains the limit.

Deactivate

Use deactivate when the buyer removes the product from a domain/device.

{
  "success": true,
  "activations": 0
}

Boot verification

Protected packages can also verify that the product files were signed with the product signing key.

Boot verification checks:

the license key;
the product ID;
the signed package manifest;
the product signing public key;
whether the product signing key is still active;
whether the package signature is valid.

If the product should be signed and the signature is missing, wrong, revoked, or mismatched, the SDK should refuse to boot the protected part of the product.

API keys in shipped products

Use product client API keys for software you distribute to buyers. They are scoped to license operations for one product, which limits damage if a key is extracted from a shipped build.

Do not use broad account keys inside distributed software. Keep broader keys for internal tools, CI, and private automation.

Product client keys and license files

When a buyer downloads a licensed product from Lyrinox Market, the download package includes a lyrinox folder with the buyer's license file and product client key file.

Your product should read those files when possible. That gives buyers a smoother setup and reduces support tickets.

Test before shipping

Use the SDK Sandbox to send live validation, check, activation, and deactivation requests against your own seller account.

Use it to confirm:

your API key is authorized;
the product ID is correct;
a license key belongs to that product;
activation limits behave the way you expect;
native SDK and integration requests are tracked separately.

After the sandbox works, test the actual SDK binding you plan to ship with your product.

Practical rules

Validate on first run.
Activate on install or first successful setup.
Check periodically for long-running software.
Deactivate when the customer intentionally removes the install.
Fail closed for signed package checks.
Show buyers clear error messages that tell them whether the issue is the key, activation limit, account, or product setup.