License validation vs activation: the practical difference

The short version

Validation checks the current state of a license key. It can tell your application whether the key is active, expired, product-scoped correctly, and associated with the current machine.

Activation registers a machine fingerprint against the key. That registration occupies one of the key's allowed activations until the machine is deactivated or the activation is otherwise removed.

• Validate when the application starts and before sensitive paid behavior.
• Activate when a customer approves a new installation or device.
• Unlock paid behavior only when the validation result is valid and the current machine is activated.

What validation does

A validation request is a read-and-check operation. GrebKey checks the key and, when a machine fingerprint is supplied, reports whether that exact machine already has an activation.

Validation does not create an activation. If the key is valid but the device has not been registered, the response can still report a valid key with machine_activated set to false.

What activation does

Activation is the state-changing step. GrebKey records the machine fingerprint for the key, rejects a new registration when the key has reached its activation limit, and treats an already-registered machine idempotently.

Choose an activation flow that matches your threat model. GrebKey exposes a public license-key activation endpoint, while the SDK activation helpers use an API-key-protected dashboard route. Never embed a gk_live_ API key in distributed desktop software, installers, browser bundles, or client-side plugins.

The application decision

Treat key validity and machine activation as two inputs to the same authorization decision. A key can be valid for the product while the current machine is not one of its approved installations.

For the standard GrebKey SDK flow, allow paid behavior only when valid is true and machine_activated is true. If the machine is not activated, send the user through your chosen activation experience instead of silently activating it during validation.

Caching does not merge the concepts

The Python and Node SDKs can cache validation results and use a configured offline grace period during network failures. A cached result still represents a validation decision; it does not perform a new activation.

The SDK from_cache flag tells you that cache supplied the result, but it does not distinguish a fresh cache hit from an offline-grace fallback. Design customer messaging around that boundary instead of promising more detail than the SDK returns.

Implementation checklist

Keep the first version explicit. A small flow with visible states is easier to test and support than a validation call that also tries to repair activation state.

• Create the key with an activation limit that matches the license you sold.
• Collect or generate a stable machine fingerprint through the SDK.
• Activate the machine through a deliberate, appropriate flow.
• Validate on startup and require both valid and machine_activated.
• Provide a way to deactivate old machines before customers run out of seats.
• Keep API keys and other private credentials in trusted server-side code.