LicenPro
DocumentationPlatformSystem overview

System overview

How the LicenPro dashboard, hosted REST API, and client SDKs fit together—from first product setup through runtime validation in your shipped application. The .NET SDK is documented today; additional language SDKs (with examples per stack) are on the roadmap.

Three surfaces

Dashboard (JWT) is where vendors define products, releases, keys, and licenses. The REST API is the automation and runtime boundary for validation, activations, sessions, and telemetry. Client SDKs ship inside your app and verify signed license material using the product public key. The .NET SDK is available today; LicenPro is expanding to first-class SDKs for more languages and runtimes (for example VB, Java, Python), and this documentation will add language-specific examples for each stack alongside the REST API—any environment can integrate via HTTPS in the meantime.

Credentials at a glance

Dashboard & management HTTP calls use Authorization: Bearer <JWT> after you sign in. That JWT is tied to your operator session (who you are in the vendor portal). Use it for routes that manage organizations, products, licenses, and similar—never paste it into customer apps.

Anonymous validation from servers or a client SDK uses the product X-API-KEY on routes such as POST /api/Licenses/validate. You create and copy that key from the dashboard in the product’s API / credentials area, or wherever your deployment surfaces it for your signed-in user (including account or profile pages that list product keys). It is not your login password. Treat it like a secret: store it in server config or a secure vault; ship it to end-user binaries only when you intentionally embed it for anonymous product calls.

RSA signing material: each product has a private signing key that stays on LicenPro / your hosted boundary—never distribute it and never put it in client binaries. Apps and SDKs use only the public key (or equivalent public material) to verify that license.bin was signed for that product. So in short: JWT = vendor operator; X-API-KEY = product identity for anonymous API calls from your code; public key = verify licenses in the field; private key = stays server-side only.

Hosted API base (cloud): https://licenpro.runasp.net/api. Route-by-route summaries: REST API overview.

Who does what

  • Vendor operators — work in the browser dashboard under your organization; day-to-day authoring of products, releases, keys, and licenses.
  • Integrators & automation — call the same HTTPS surface from CI, billing, or internal tools (JWT for operator-scoped routes, or product key only where a route is designed for anonymous access).
  • Customer applications — use a supported client SDK (today: .NET) or call the REST API from your stack; verify license.bin offline with the public key and optionally refresh state online against https://licenpro.runasp.net/api. More language SDKs and per-language examples (e.g. VB, Java, Python) are planned.

Phase 1 — Configure (dashboard)

This is the left side of the diagram: everything you do before a customer machine ever runs your app.

  1. Organization — tenant boundary for members, invitations, and products.
  2. Product — anchor for API keys, releases, entitlements, and every issued license.
  3. Releases — version lines so licenses and update checks target a specific build or channel.
  4. Features & entitlement sets — optional packaging of capabilities into SKUs you assign to licenses.
  5. RSA keys — generate per product before issuing licenses; only the public key is distributed to apps.
  6. Licenses — choose model (perpetual, trial, subscription, floating, node-locked, …), set limits, export license.bin and the license key.

Deeper reads: Organizations · Products · Releases · Features & entitlements · RSA keys · Licenses (vendor) · First product · First license.

Phase 2 — Operate (REST API)

The middle of the diagram: the hosted boundary at https://licenpro.runasp.net/api (substitute your own host when self-hosting).

  • Online validation — POST /api/Licenses/validate with the product X-API-KEY when you want the server to evaluate policy, hardware binding, or revocation in real time.
  • Activations & sessions — optional seat enforcement, floating concurrency, and heartbeat-style visibility for support and compliance.
  • Telemetry & updates — SDK-facing routes for settings, update metadata, and optional log shipping (see SDK topics for how managers call these).
  • Automation — provision or retire licenses from backend jobs using JWT-scoped management routes where your RBAC allows it.

Start here: REST API overview · Licenses API · Activations & sessions · Telemetry & logs.

Phase 3 — Enforce (client SDKs)

The right side of the diagram: code that ships inside your process. .NET is fully covered in this site today; additional SDKs and dedicated examples per language (including VB, Java, Python, and others) will appear here as they ship. Until then, any stack can use the same HTTPS contract as the REST API.

The following steps use today’s .NET types and entry points; other SDKs will mirror the same lifecycle with idiomatic APIs per language.

  • Bootstrap once — resolve ServerBaseEndpoint (must include /api), load JSON settings if you use them, then run SdkBootstrap.OnApplicationStartup() on desktop hosts before UI.
  • Offline trust — LicenseClient verifies the RSA signature on license.bin using the embedded public key material; no private key in the client.
  • Online refresh — optional paths back to https://licenpro.runasp.net/api for validation refresh, activations, sessions, feature usage, and license-aware updates.

Continue with .NET SDK overview · Configuration & bootstrap · .NET integration · LicenseClient lifecycle.

Optional runtime paths

After the core loop works, teams usually add one or more of the following: