Protection Profiles

Choose the right binding mode for your product: none, hostname-bound, or hardware-locked licenses.

A protection profile controls how tightly a license is tied to a specific environment. You select it per product in the dashboard. The profile determines what value your integration should send as identity_value in POST /api/v1/license/check.

The Three Profiles

Profile	Best For	`identity_value`	Seat Binding
`none`	Floating licenses, API keys, pure entitlement checks	A fixed sentinel (e.g., all-zero HWID)	No binding; consumed on first use
`hostname`	Web apps, SaaS backends, WordPress plugins, browser extensions	Bare domain / FQDN	Bound to the hostname/domain
`hardware`	Native apps, CLI tools, servers, appliances	64-char hex SHA-256 HWID	Bound to the device fingerprint

Choosing a Profile

text

Is the software running on hardware you don't control?
├─ Yes, it's a web app / SaaS / plugin ──→ hostname
└─ No, it's a native binary / appliance
   ├─ Need strict anti-sharing? ──────────→ hardware
   └─ Need floating/key-only access? ─────→ none

`none` — License key only

Use this when you want a license to work anywhere with just the key. It is the simplest model but offers the least protection against sharing.

Typical use: internal tools, API-key-style access, trial tokens, or low-risk products.
Integration: send the same sentinel identity_value on every check.
Example sentinel: 0000000000000000000000000000000000000000000000000000000000000000
Important: a none license can only be used once. The first successful check creates an activation and consumes the license. Subsequent checks return denied_seat_limit, even with the same sentinel.

`hostname` — Bind to domain/FQDN

Use this for anything that runs on a customer's server or website.

Typical use: WordPress plugins, self-hosted apps, customer backends, SaaS tenants.
The server normalizes the domain (lowercase, strips protocol/path/www.), so https://www.Example.com/checkout becomes example.com.
Each unique normalized domain consumes one activation seat.
Product type must be web.

`hardware` — Bind to HWID/device fingerprint

Use this for native software where you want to limit sharing and enforce device limits.

Typical use: Windows/macOS/Linux desktop apps, server appliances, CLI tools.
The client generates a 64-character lowercase hex SHA-256 hash from stable hardware attributes (machine ID, primary MAC, boot-disk serial).
Replacing the motherboard or boot disk changes the HWID and consumes a new seat.
Product type must be native.

Product Type vs Protection Profile

Product type	Allowed profiles	Identity type sent
`native`	`none`, `hardware`, `hostname`	`hwid`
`web`	`none`, `hostname`, `hardware`	`domain`

The product type drives how the server validates and normalizes identity_value. Choose the type that matches where your software runs, then pick the profile that matches your sharing tolerance.

Example Mapping

Product	Type	Profile	`identity_value`
Self-hosted analytics plugin	`web`	`hostname`	`customer.com`
macOS design tool	`native`	`hardware`	`a1b2...f0` (64 hex)
Internal API key	`native`	`none`	fixed sentinel

Next Steps

License API — copy the request example for your profile.
Getting Started — create a product and issue a license.