How to Transfer a Software License to a New Computer
A customer gets a new laptop. Their node-locked license is bound to the old one. Without a self-service way to move it, this becomes a support ticket every single time — and it happens constantly, since hardware turnover is routine. Here's the real mechanism that avoids that.
The actual flow: deactivate, then reactivate
A license's activation limit isn't a one-time allocation — it's a live count of currently-active devices. Freeing a seat is just removing one of those device records. PermitCore's Customer Portal exposes exactly this as a self-service action:
POST /portal/{tenantSlug}/deactivate { "licenseKey": "PERMIT-XXXX-XXXX-XXXX-XXXX", "activationId": "..." }
This removes the specific device's activation record and decrements the license's active-device count by one — freeing exactly one seat. The customer then runs your app on their new machine and calls activate() as normal; since a seat is now free, it succeeds and consumes it. No admin involvement, no support ticket, no manual seat-count edit.
Why this needs real authentication, not just a click
Removing someone else's active device is a real action — done maliciously, it could kick a legitimate user off their own machine. Depending on how strict a tenant wants their portal, this can require nothing beyond possessing the key itself (fine for most consumer software), a one-time email code sent before the deactivation is allowed, or a full customer account login. All three tiers use the same underlying deactivate mechanism — they differ only in what has to happen before it's allowed to run.
What if the old machine is gone and can't be reached?
This is the case a purely device-initiated "sign out" button can't handle — a stolen or dead laptop obviously can't call an API to deactivate itself. That's exactly why deactivation is a server-side action triggered by the customer (via the portal, using the license key or their account — not the old device), not something the old device has to cooperate with.
What this looks like without self-service
The alternative — every transfer needs a support email and a manual admin seat reset — doesn't scale past a handful of customers, and it's the single most common support request a node-locked product with any real customer base will see. Building the self-service path once removes an entire category of recurring support load.