Activation
Use this page to bind a license to a device or container and return the signed entitlement state for that binding.
Who This Is For
- application developers implementing first-run license binding
- teams enforcing device or container activation limits
- AI agents wiring initial runtime activation into an app
When To Use This
Use activation when a client needs to establish or re-establish a bound runtime identity.
If you want a normal recurring validation flow after activation, use Validation. If you need a read-only entitlement check that does not refresh validation timestamps, use Check.
How It Works
POST /api/v1/license/activate:
- uses
Authorization: License <license-key> - requires an
Idempotency-Keyheader - accepts a runtime binding payload
- returns a signed entitlement envelope
Activation is the explicit runtime path that accounts for device or container binding. It is the right starting point when you care about activation limits, device inventory, or first-run seat consumption.
The response is signed, so the client should verify signature against GET /api/v1/system/public-keys before trusting data.
Example
curl -X POST https://api.licensekit.dev/api/v1/license/activate \
-H "Authorization: License $LICENSE_KEY" \
-H "Idempotency-Key: activate-host-123" \
-H "Content-Type: application/json" \
-d '{
"fingerprint": "host-123",
"hostname": "designer-mac",
"app_version": "1.4.0"
}'Typical response fields:
{
"data": {
"license_id": "lic_123",
"status": "active",
"license_type": "subscription",
"device_id": "dev_123",
"next_check_at": "2026-04-17T00:00:00Z",
"features": []
},
"signature": {
"kid": "sig_123"
},
"meta": {
"request_id": "req_123"
}
}Common Mistakes
- omitting
Idempotency-Keyand making retries harder to reason about - trusting the runtime
datapayload before signature verification - using an unstable fingerprint and then misdiagnosing the resulting activation churn
- confusing activation with a management-side device reset or blacklist action