Software licensing API: activation, validation and heartbeats

Choose a language and operation, then call the SDK. It handles activation, device identity, signature verification, cache, heartbeats and metered reserve, commit and cancellation.

Startup or activation screenBefore paid featuresOn application exit

Common scenario snippets

In these examples, client comes from startup, path is your export path, and exportReport / export_report is your business function. Metered jobID is the stable ID persisted by your application.

See the complete code → · Quick start · See metered integration and retries →

Put business code in the callback.

The SDK runs business only when permitted. RunFeature does not deduct usage; RunMeteredFeature reserves, commits after success and cancels after failure. Retry the original job to settle confirmation without repeating completed business.

Complete SDK method reference

The scenarios above are short call snippets. Below are the current language’s public methods, properties and utilities, including full signatures, parameters, results, errors, configuration and data fields. The reference follows the selected language and identifies capabilities that are unavailable in a wrapper.

Expand HTTP requests and responses (custom clients or troubleshooting)

The protocol below is implemented by the SDKs. Applications using these nine SDKs do not need to implement it again.

First activationRuntime heartbeatCheck access before business operationsDeactivate before device transfer

These eight endpoints authenticate license and device identity, without login cookies, CSRF or vendor management keys. Floating sessions release on exit; node-locked devices keep registration.

How do I check access after activation, validation or a heartbeat?

Check for HTTP 200 and read data.activation_id. Include this ID in later validation, heartbeat, metering and deactivation requests.
Verify with the pre-trusted product public key data.lease signature, then verify the product, device, validity and features. Decoding payload into JSON alone does not prove a license is valid.
With the SDK, the first two steps are automatic. RunFeature checks access before business; RunMeteredFeature manages reserve, confirm and cancel for counters.

The SDK stores signed caches and sends policy-based heartbeats. Do not erase a valid cache just because a request times out. For explicit revocation, release or expiration, use the SDK result to block protected features.

What do decoded payload fields mean?

The example below only explains the data. If implementing signature verification, use the received payload's original bytes; do not reorder or serialize the JSON before verifying.

Retries, heartbeats and billing

Required for activation, deactivation and feature metering Idempotency-Key, up to 80 characters without whitespace. Generate a new value for each operation; keep the same value and body when retrying it. Optional for validation and heartbeats; the SDK handles its own request IDs.

While authorization remains valid, identical validation and heartbeat requests can be retried for one hour without duplicate billing. After that window, use a new request key; an old key may be treated as a new request. Activation, deactivation and feature usage keep durable idempotency records.

Each successful activation, validation, heartbeat or unbinding uses one platform API call. Failures and idempotent replays are not counted again; local CheckFeature makes no request. Consume only deducts software feature uses, not this platform API quota. quantity is the number of feature uses consumed.

Heartbeat interval, offline duration and permanent offline follow Licensing policies settings.payload.expires_at is the current signed cache's expiration, not the license's final expiration. Check license details for the latter.