Customer portal

Keylight hosts a customer-facing portal at portal.keylight.dev. It’s where your customers — not you — go to manage the licenses they bought from you: see their keys, free up a device, upgrade a tier, or recover a key they lost. You don’t build or host anything; link your app and support pages straight to it.

There are two ways in, and the difference matters:

Sign in — for people who already own a license. Everything below the “Signing in” section lives here.
Claim a legacy key — the one public, pre-sign-in page, for customers migrating from a previous vendor who don’t have a Keylight license yet.

Signing in

Customers enter the email they bought with and receive a magic link — no password. Clicking it opens their dashboard.

A link is only sent to an email that already has at least one license. An unrecognized email gets the same “check your inbox” response but no email — this prevents using the form to probe who your customers are.

What customers can do once signed in

The dashboard lists every license tied to their email, across all of your apps. For each license they can:

View and copy the key.
Recover a lost key — there’s no separate “recovery” page; the key is right here, and an “email me this key” button re-sends it to the address on file.
Manage devices — see active devices and remove one to free a seat. The seat frees immediately.
Upgrade — when you’ve enabled upgrades for the product, they pick a higher tier and go straight to your payment provider’s checkout. No key or email re-entry — the signed-in session already identifies them. See Upgrades.
Manage their subscription — for subscription licenses, a button hands off to your payment provider’s own billing portal (Stripe, Gumroad) to update payment details or cancel.
Add seats — on a license sold in multiples, buy more of the same tier without changing tier. The same key grows; nothing to re-enter in your app. See Adding seats.
Choose which devices to keep — when a subscription’s seat count is dropping at the end of the paid period, a banner names how many devices to remove and by when, and a chooser lets the customer decide which ones rather than having it decided for them. See Seat changes on a subscription.

Which actions appear is controlled per product by the customerPortal settings on your app configuration.

Claiming a legacy key

If you’re moving customers onto Keylight from a previous vendor (Gumroad, Paddle, a homegrown system), they can self-serve the switch at:

https://portal.keylight.dev/p/<your-tenant-id>/claim/<product-id>

The customer enters their existing (old) license key and purchase email. Keylight verifies the pair, mints them a fresh Keylight license, and emails it to them — using your branding, not Keylight’s. They can then sign in normally to manage it.

Verification runs one of two ways, configured per product:

Table — you hand Keylight a list of valid (key, email) pairs (optionally with a target tier per row). Keylight stores them and matches against that list.
Webhook — Keylight POSTs { key, email } to a URL you host, signed with a shared secret (X-Keylight-Signature: sha256=…); you reply { "ok": true, "keyTypeId": "…" }. Use this when your old system is the source of truth.

Either way the claim is idempotent — a given legacy key can be claimed exactly once. Failed verification never mints anything.

Linking customers to the portal

Lost key / general support: link to https://portal.keylight.dev.
Migrating from another vendor: link to https://portal.keylight.dev/p/<tenant>/claim/<product>.
In-app: point an “Upgrade” or “Manage license” button at https://portal.keylight.dev.

Branding

The portal at portal.keylight.dev is Keylight-hosted. Transactional emails it sends (license delivery, sign-in links) are fully white-labeled to your brand. A fully brand-customized portal served on your own domain is on the roadmap.