QuantumLock does not require a phone-home on every launch. A license can be validated three ways, and your application chooses how strict to be.

​
Validation modes

Hybrid mode never embeds your API key in shipped software: the hybrid endpoint authenticates the license, not you. Your platform API key stays on your own servers.

​
The activation flow for shipped software

1

Issue

Your backend calls POST /api/v1/v2/artifacts with the customer’s entitlements, a validity window, an optional grace period, and — if you want machine locking — a binding object describing the device properties you will enforce.
2

Deliver

Deliver the artifact (JSON or compact string) to the end user with your product — as a file, an environment value, or an install-time download from your own systems.
3

Validate at startup

Embed the Python SDK. HybridLicenseValidator.validate() verifies the local license first (the product starts immediately), then syncs revocation in the background. LicenseValidatorV2 gives you full artifact validation with binding and epoch checks.
4

Re-check in the background

The hybrid validator maintains a persistent local revocation cache keyed off the hybrid endpoint’s revoked flag, and honors the configured grace period when the API is unreachable.

​
Offline validation

Truly offline validation rests on three artifacts you can fetch while connected and keep:
  1. Verification keys — GET /api/v1/v2/keys (or GET /api/v1/evidence/keys). Requires the quantumlock:read scope: verification is offline, but obtaining the keys is not anonymous.
  2. Status proofs — POST /api/v1/v2/status-proof issues a signed, TTL-bounded statement of a license’s status. LicenseValidatorV2.cache_proof() stores it; validate_offline() answers from the cache first.
  3. Revocation set + epoch — GET /api/v1/v2/revocation. The client persists the highest epoch seen; older sets are rejected (anti-rollback).
Offline validation is software protection, not hardware security: a determined attacker with full control of the machine can tamper with a client-side check. Pair offline validation with evidence bundles when you need proof that holds up to third parties.

​
Device binding

Binding restricts an artifact to device properties you choose (for example a machine identifier your installer computes). You supply the properties at issue time (binding) and again at validation time (device_fingerprint); validation fails with binding_mismatch when they diverge. QuantumLock does not invent a fingerprint for you — you decide what identifies a machine in your product.

​
Grace periods

Set grace_days on the artifact. After exp, validation keeps succeeding until grace_until with in_grace_period: true and status grace_period, so you can degrade politely (warn, restrict features) instead of failing hard while a renewal is processed.

​
Plans and allowances

License generation and activation validation are counted against your workspace’s plan allowances; when a monthly allowance is exhausted the API refuses further generation with an explicit message. Check where you stand with:
Allowance sizes and pricing are managed in the SoftQuantus platform — see Pricing.