License keys

Availability

License keys live inside the Customers module, which is in private beta. Find them at Audience → Customers.

What a license key is

A license key is a secret string you issue to a paying customer, which their copy of your software redeems to unlock itself. AppGram mints the key, records which devices have activated it, and lets you revoke it later.

This is for software you distribute — a desktop app, a mobile app, a plugin, a self-hosted install — where the customer needs something to paste in. If your product is a hosted web app your users simply log into, you probably want verified identity instead.

Minting a key

There are two entry points:

• Mint license key in the Customers page header — for a customer who isn't in the directory yet.
• The License keys section on an existing customer's record — to bind a key to someone already there.

The mint form asks for:

• Email — the buyer. This is what ties the key to a customer record.
• Name — optional.
• External ID — the identifier from whatever system took the money, for example stripe_cus_123. Fill this in; it is what lets you reconcile a key against a payment later.
• Plan — a free-text tier such as pro, team, or enterprise. Your app decides what each plan unlocks.
• Max devices — how many concurrent seat activations the key permits.
• Expires — an optional expiry date.

The key is shown exactly once

When the key is minted, AppGram displays the plaintext once and never again. Copy or download it at that moment and either store it in your password manager or hand it straight to the customer.

After that, only the last four characters are retained, which is enough to identify a key in a support conversation but not enough to use it. If a customer loses their key, you cannot recover it — mint a replacement and revoke the old one.

Statuses

Every key is in one of three states:

• Active — working, and able to accept new activations up to its seat limit.
• Revoked — deliberately turned off by you.
• Expired — past its expiry date.

Seats and activations

Each key shows its usage as activations against the limit, for example 3 / 5 seats. An activation is created the first time a device redeems the key.

View activations on a key lists the devices currently holding a seat, each with its device name, platform, when it first activated, and when it was last seen. That last-seen timestamp is the quickest way to spot a seat that is being held by a machine nobody uses any more.

Editing a key

Plan, max devices, and expiry can all be changed after minting. The key string itself cannot.

One behaviour worth knowing: lowering max devices below the number of currently active seats does not kick anyone off. Existing activations keep working; new ones are rejected until usage falls below the new limit.

Revoke versus delete

These are not the same operation and the difference matters:

• Revoke — the safe option. The key stops working, but the record stays, so you keep the history of who had it and what happened to it. Use this for refunds, cancellations, chargebacks, and suspected sharing.
• Delete — a hard delete. It cascades every activation and removes the audit row entirely. Use it only when you genuinely need the record gone, such as a key minted in error or a data-erasure request.

When in doubt, revoke. A revoked key can still answer the question what did we issue this customer and when did we turn it off; a deleted one cannot.

Managing keys programmatically

License keys are available through the AppGram API, so issuing a key can be part of your checkout rather than something a person does by hand. The API supports listing keys, fetching one with its activation list, creating, updating, revoking, and deleting.

The usual pattern is to mint a key from your payment webhook when a purchase completes, and revoke it from the cancellation or refund webhook. The plaintext key is returned only on the create call — the same one-shot rule as the dashboard — so capture it in that response and email it to the customer straight away.

How your application redeems and checks a key at runtime depends on your platform; see the developer documentation for the endpoints and examples.

Best practices

• Always fill in the external ID. Without it, matching a key back to a payment months later is guesswork.
• Set max devices deliberately. Too low generates support tickets when someone buys a new laptop; too high invites sharing.
• Use expiry dates for time-limited licences and trials, rather than relying on remembering to revoke.
• Automate minting from your payment provider. Manual minting does not survive contact with a busy week.
• Check activations before assuming abuse. A customer with five activations across two laptops and a rebuilt machine is usually not sharing their key.