Validation

Use this page to validate a bound license and refresh its validation timestamps during normal runtime operation.

Who This Is For

• developers implementing periodic online license enforcement
• teams that want the server to record recent validation activity
• AI agents wiring a standard runtime check loop

When To Use This

Use validation for the normal recurring runtime path after the client is already bound.

If you need a non-mutating entitlement read, use Check. If you are establishing the binding itself, use Activation.

How It Works

POST /api/v1/license/validate:

• uses Authorization: License <license-key>
• accepts a runtime binding payload
• returns a signed runtime entitlement envelope
• refreshes validation timestamps as part of the runtime flow

Validation is the usual hosted-runtime control loop. It is a good fit when your app needs the current entitlement state and the backend should know the license is still validating successfully.

As with all signed runtime envelopes, verify signature before trusting data.

Example

curl -X POST https://api.licensekit.dev/api/v1/license/validate \
  -H "Authorization: License $LICENSE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "fingerprint": "host-123",
    "app_version": "1.4.0"
  }'

Common response fields:

{
  "data": {
    "license_id": "lic_123",
    "status": "active",
    "device_id": "dev_123",
    "next_check_at": "2026-04-17T00:00:00Z",
    "features": [],
    "version_eligibility": {
      "enforced": true
    }
  },
  "signature": {
    "kid": "sig_123"
  }
}

Common Mistakes

• using validation when you actually want a read-only check
• skipping app_version when version gating is part of the product contract
• treating a parsed success response as trusted before cryptographic verification
• confusing runtime validation failures with management token scope failures

Related Pages

• Activation
• Check
• Runtime Verification
• Error Handling