Skip to content

LicenseKit Overview

Use this section to understand where LicenseKit fits before you wire it into your product, billing flow, or CRM.

Who This Is For

  • developers evaluating LicenseKit for desktop, on-prem, edge, installable, plugin, firmware, model, or data products
  • teams connecting Stripe, HubSpot, Pipedrive, Zoho CRM, or a custom commerce workflow to license fulfillment
  • AI coding agents wiring licensing into an application
  • operators who need runtime enforcement plus customer/order visibility, reporting, and exports

When To Use This

Start here if you need to understand the product shape before picking a deeper guide.

The current product posture is suitable for active development and live trial usage. Do not describe it as broadly production-proven at scale without new evidence.

Positioning

LicenseKit is the post-sale access layer for software and digital IP.

The commercial system closes the deal or payment. LicenseKit creates the access state, enforces it at runtime, and preserves the evidence needed by support, customer success, finance, and compliance workflows.

The normal loop is:

  1. define what you sell as products, policies, features, seats, device limits, versions, and usage rules
  2. connect the system where the sale happens, such as Stripe, HubSpot, Pipedrive, Zoho CRM, or your own API workflow
  3. create customer, order, subscription, and license records linked to that external source
  4. validate access from the protected product
  5. inspect activity, customer summaries, license audits, usage ledgers, settlement views, and frozen exports

How It Works

LicenseKit is an API-first licensing, fulfillment, and reporting backend with three distinct auth surfaces:

SurfaceHeaderUse it forSuccess envelope
ManagementAuthorization: Bearer <token>products, policies, customers, orders, subscriptions, licenses, devices, events, webhooks, reporting{data, meta}
RuntimeAuthorization: License <license-key>activation, validation, check, consume, deactivate, offline issuance, floating leases{data, signature, meta}
Systemnone/health, /healthz, /readyz, /metrics, /api/v1/system/public-keysendpoint-specific

The shortest path to a direct API integration is:

  1. create or load a management key with the minimum scopes required for setup
  2. create a product and policy
  3. issue a license
  4. validate or check that license from the protected application
  5. verify the runtime signature against GET /api/v1/system/public-keys

Use these pages next:

Example

This is the minimum runtime shape to keep in mind:

ts
import {
  PublicKeyStore,
  RuntimeClient,
  SystemClient,
  verifyRuntimeResult
} from "@licensekit/sdk";

const baseUrl = "https://api.licensekit.dev";

const runtime = new RuntimeClient({
  baseUrl,
  licenseKey: process.env.LICENSE_KEY!
});

const system = new SystemClient({ baseUrl });

const result = await runtime.validateLicense({
  body: { fingerprint: "host-123" }
});

const publicKeys = await system.listPublicKeys();
const verification = await verifyRuntimeResult(
  result,
  new PublicKeyStore(publicKeys.data)
);

if (!verification.ok) {
  throw new Error("runtime signature verification failed");
}

Common Mistakes

  • sending a management bearer token to runtime routes
  • treating runtime signature verification as optional
  • guessing required scopes instead of reading x-required-scopes from api/openapi.yaml
  • describing reporting exports as live reruns instead of frozen artifacts
  • treating orders and subscriptions as a billing engine instead of linked external records
  • treating a CRM deal or Stripe payment as the license itself instead of the source event that creates license state

Prototype docs shell for the rewrite workspace.