We are currently evaluating Cryptlex for our products and require node-locked offline activation.
Since our devices are not connected to the internet, we are looking for a way to make the offline activation flow as convenient as possible for users and service engineers.
One option would be a small internal tool running on a connected laptop (e.g. a service engineer laptop) that:
uploads the offline activation request generated by the device
downloads the corresponding offline activation response
From the documentation, it appears that creating an offline activation response is only possible via the admin portal or customer portal, and that this step is not exposed via the Web API.
Is this correct, or am I missing an API-based approach to automate the offline activation response generation?
Are there any recommended or supported alternatives for automating this workflow?
it looks like that authorization is necessary for this endpoint. Can you please comment on which permissions the access token needs to have to create an offline activation response?
thanks for the clarification. I have one follow-up question regarding the API design.
For the CreateOfflineActivation endpoint, a licenseId is required, whereas for the online activation flow the licenseKey alone is sufficient.
In offline scenarios, where the activation is intentionally decoupled from the device and performed on a separate, connected system (e.g. a service engineer laptop or a customer backend), this creates an additional hurdle:
Either the licenseId has to be shared alongside the licenseKey, or
The offline activation tool needs an access token with license read permissions to resolve the licenseId from the licenseKey.
Both options somewhat weaken the otherwise clean separation between the offline device, the license key handed to the customer, and the activation tooling.
Could you share the rationale behind requiring licenseId for offline activation?
Are there recommended patterns to handle this securely and conveniently in air-gapped or customer-side activation workflows?
The rationale behind requiring the licenseId for the CreateOfflineActivation endpoint is tied to how this flow is designed to be used. This endpoint is primarily invoked from the Admin Portal or Customer Portal, where the licenseId is already known.
When the same endpoint is used from another interface, it is assumed that the system performing the offline activation can access the license details using the licenseKey. This intent explains why this endpoint requires a licenseId rather than a licenseKey.
From a technical/API-design perspective I can see two possible rationales for requiring licenseId:
Cryptlex seems to generally model operations on stable resource identifiers (IDs) rather than alternate identifiers such as licenseKey (which is also consistent with other endpoints).
In offline workflows it’s beneficial if the offline activation request artifact can be transported/shared without embedding the full license key (to reduce accidental leakage). In that case the response generator must already “know” which license to apply the request to, and a canonical licenseId is the natural handle.
That said, for the “service laptop / customer-side activation tool” scenario this still creates friction, because it forces an additional lookup step (key → id) and therefore either:
sharing licenseId alongside the licenseKey, or
granting the tool a way to resolve the ID.
Would you consider one of the following to support this pattern more cleanly?
Allow licenseKey as an alternative input (server resolves to licenseId internally), or
Provide a minimal “resolve license ID from license key” operation with scoped permissions (or a customer-portal-token compatible approach), so offline activation tools don’t need broader license read access.
Happy to align with your recommended best-practice pattern, but right now licenseId as a hard requirement makes the decoupled offline activation tooling noticeably harder to implement cleanly.
