DOCS LLMs

Create a license

Create a license after a purchase in your own store or another payment provider. Your backend makes this call; never put its secret API key in a browser, desktop app, game or plugin.

  1. In your product's Plans page, create or select the license plan. Copy its Key (for example pro-annual), not its display name or record UUID. The plan supplies license duration, seat count, licensing mode and entitlements.
  2. Create a secret (sk_) key with the licenses:create scope in API Keys settings. Keep it in your backend's secrets. Publishable (pk_) keys cannot issue licenses.
  3. Make the request using your product slug and that plan key:
curl --fail-with-body https://licenseseat.com/api/v1/products/your-product/licenses \
  -H "Authorization: Bearer $LICENSESEAT_SECRET_KEY" \
  -H "Content-Type: application/json" \
  --data '{"plan_key":"pro-annual","metadata":{"order_id":"your-order-id"}}'

A successful request returns HTTP 201 and a license object. Its key is the license key to store and deliver to your buyer. A lifetime plan can return expires_at: null; unlimited seats can return seat_limit: null.

Verify the purchase on your backend before issuing. Deduplicate payment webhook retries using your order ID and retain the returned license key. Adding metadata alone does not make this endpoint idempotent: two successful requests can create two licenses. If a response is lost, reconcile the purchase before retrying blindly.

The minimal request does not need owner parameters. Optional owner_type and owner_id associate an existing customer record; they do not create a customer or accept an email address. LicenseSeat.com accepts owner_type: "Customer" and an existing Customer UUID in your organization. Other hosts of the open-source engine can configure their own owner resolver.

For revocation, POST /api/v1/products/{slug}/licenses/revoke takes license_key and an optional reason, using a secret key with licenses:revoke. It disables server-side usage. A disconnected device cannot learn of revocation until it reconnects or its permitted offline artifact expires.

Full request and response schemas include both administrative endpoints. These operations do not belong in distributed client SDKs.