Skip to main content
When creating a license product, you choose a lock type that determines how keys are bound to devices. There are three options.

none — No Device Binding

Any device can verify the key. No hwid field is needed in the request. This is the simplest option for software that does not need device-level restrictions.
Use none when you only care about whether the key is valid, not which device is using it. Activations still apply — each unique verification counts as an activation if max_activations is set.

hwid — Hardware ID Lock

Each device sends a machine fingerprint (hardware ID). The key auto-binds to the HWID on the first verification call. Subsequent calls from the same HWID are idempotent. A new HWID consumes an activation slot.
If the lock type is hwid and the request does not include an hwid field, the API returns the HWID_REQUIRED error (HTTP 403).

Generating a Hardware ID

Combine machine-specific values and hash them to produce a consistent, unique identifier. The goal is a string that stays the same across reboots but differs between machines.
For stronger HWIDs, include additional hardware identifiers like MAC address, CPU ID, or disk serial number. The more inputs you combine, the harder it is to spoof.

ip — IP Address Lock

The API auto-detects the caller’s IP address and binds it to the key. No hwid field is needed in the request. Each unique IP uses an activation slot.
IP locking is useful for server-side software (e.g. FiveM resources, web apps, bots) where the IP is stable. It is not recommended for end-user desktop software because consumer IPs change frequently.

Comparison