Floating Licenses
Use this page to manage concurrent seat pools with lease checkout, heartbeat, and checkin instead of permanent device slots.
Who This Is For
- teams selling shared concurrent access
- operators managing render pools, worker pools, or shared desktop seats
- developers implementing lease-based runtime access
When To Use This
Use floating licenses when concurrent seat count matters more than fixed activation history.
Floating behavior is a runtime overlay on top of a license policy. It is not a separate license type.
How It Works
The floating flow is:
- configure
max_floating_users - optionally set
floating_timeout_minutes POST /api/v1/license/floating/checkout- store
lease_token POST /api/v1/license/floating/heartbeatbefore expiryPOST /api/v1/license/floating/checkinwhen done
Important rules:
- checkout and checkin require
Idempotency-Key - heartbeat does not
- checkout and checkin generate signed runtime envelopes
- abandoned seats expire automatically after the timeout window
Example
Check out a lease:
bash
curl -X POST https://api.licensekit.dev/api/v1/license/floating/checkout \
-H "Authorization: License $LICENSE_KEY" \
-H "Idempotency-Key: floating-checkout-123" \
-H "Content-Type: application/json" \
-d '{
"fingerprint": "render-node-07"
}'Heartbeat:
bash
curl -X POST https://api.licensekit.dev/api/v1/license/floating/heartbeat \
-H "Authorization: License $LICENSE_KEY" \
-H "Content-Type: application/json" \
-d '{
"lease_token": "llt_abc123"
}'Check in:
bash
curl -X POST https://api.licensekit.dev/api/v1/license/floating/checkin \
-H "Authorization: License $LICENSE_KEY" \
-H "Idempotency-Key: floating-checkin-123" \
-H "Content-Type: application/json" \
-d '{
"lease_token": "llt_abc123"
}'Common Mistakes
- treating floating seats as a standalone
license_type - heartbeat too close to
lease_expires_at - expecting a separate lease-list management endpoint in the current shipped surface
- forgetting that lease checkout/checkin responses are still signed runtime responses