Licensing Models

Use this page to choose the policy model that matches how you sell access, then layer on features such as metering, floating seats, offline issuance, or version gates where needed.

Who This Is For

• developers deciding how to model a new product in LicenseKit
• operators mapping commercial terms to policy and runtime behavior
• evaluators comparing LicenseKit’s supported model set

When To Use This

Read this before creating your first policy.

In the current API, policy.license_type is the primary model selector. Metering, floating seats, offline issuance, and version eligibility are related capabilities, but they are not separate license_type values.

How It Works

Supported license types

api/openapi.yaml currently exposes these license_type values:

• perpetual
• time_limited
• subscription
• trial
• consumption

Comparison

Model	Best for	Expiry behavior	Runtime endpoints	Reporting implications
perpetual	one-time purchase with durable access	no required expires_at; may use maintenance_expires_at for upgrade eligibility	activate, validate, check, deactivate	current-state license plus audit and activity evidence
time_limited	fixed-term contracts or temporary entitlements	explicit expires_at; renewable	activate, validate, check, deactivate	expiry and renewal evidence matter
subscription	recurring access tied to a billing record	explicit expires_at; renewable; can link subscription_id	activate, validate, check, deactivate	strongest fit for renewal, linkage, and settlement reporting
trial	evaluation access	explicit expires_at; renewable when you intentionally extend a trial	activate, validate, check, deactivate	useful for conversion and lifecycle tracking
consumption	usage-based access where credits or units matter most	no model-specific expiry requirement; usage is enforced through assigned features and consume	consume, plus standard runtime reads as needed	usage-ledger and usage-summary reporting matter most

Decision guide

Choose:

• perpetual if the customer buys durable access and you only need a maintenance cutoff for updates
• time_limited if the contract ends on a date and you are not modeling a recurring subscription record
• subscription if a recurring commercial record exists and you want clean linkage to subscription_id
• trial if the entitlement is explicitly temporary and evaluation-oriented
• consumption if the primary limit is usage, not time

Feature overlays

These behaviors layer on top of a license model rather than replacing it:

• floating seats: configure max_floating_users and floating_timeout_minutes, then use floating checkout, heartbeat, and checkin routes
• offline issuance: enable allow_offline_activation and use POST /api/v1/license/offline
• metering: assign features to a license and use POST /api/v1/license/consume
• version gating: send app_version on runtime requests and manage the product version catalog

Policy and license fields that matter

At minimum, a policy create request needs:

{
  "name": "Default Policy",
  "code": "default",
  "license_type": "perpetual"
}

Common companion fields by model:

• perpetual: maintenance_expires_at on the license if you need an updates cutoff
• time_limited, subscription, trial: expires_at on the license
• consumption: feature assignments plus max_consumptions on those assignments when you need quotas
• floating: max_floating_users, floating_timeout_minutes, optional require_heartbeat
• offline: allow_offline_activation, offline_grace_days

Example

Three minimal policy shapes:

{
  "name": "Perpetual Pro",
  "code": "perpetual-pro",
  "license_type": "perpetual"
}

{
  "name": "Annual Subscription",
  "code": "annual-subscription",
  "license_type": "subscription"
}

{
  "name": "Shared Seat Pool",
  "code": "shared-seat-pool",
  "license_type": "subscription",
  "max_floating_users": 10,
  "floating_timeout_minutes": 15,
  "require_heartbeat": true
}

Common Mistakes

• treating floating seats as a standalone license_type
• using subscription when there is no recurring commercial record to link
• assuming consumption alone creates metering without feature assignments
• treating orders and subscriptions as a billing engine instead of linked external records
• forgetting that runtime version checks only apply once a product has a version catalog

Related Pages

• Quickstart
• Auth And Scopes
• SDK Overview