Versions (editions)
A version — also called an edition — is a stable label that tells your application which feature set to unlock. A single product can ship as Standard, Gold and Platinum editions from the same codebase: each carries a different version, and your code switches on it. Every product has a default “Full” version (code full) until you define more.
A version is two things: a human-readable label (for example Gold) and a short, stable code (for example gold). Your application never reads the label — it reads the code.
A version is attached through the SKU
A product can be assigned several versions. Which one a customer actually receives is decided where the product meets the SKU: when you put a product into a SKU, you pick the version it ships with there.
This means the same product can carry a different edition in different SKUs:
- Photo Editor inside the Standard SKU ships with version
standard. - Photo Editor inside the Gold SKU ships with version
gold.
The customer activates one serial, KEYZY resolves the SKU → product → version, and the license your application receives already contains the right edition code. There is nothing extra to configure on the device.
Why a version code, not the SKU name
Your SKU number and name are catalog data: you rename them, reprice them, retire and replace them as your offering changes. If your application branched on the SKU, every such change would risk breaking feature gating in shipped binaries.
A version code is the stable contract between your catalog and your code. You commit to gold once, and your application can trust it unconditionally — regardless of how the SKU around it is renamed or restructured later. Editions decouple “what your code checks” from “how you package and sell.”
This pays off most as your catalog grows, because one version can live in many SKUs. The same gold edition might back a dozen SKUs — different prices, regions, bundles, campaigns, renewals — yet your code still checks a single code. Without editions, your application would have to know every SKU name that counts as “gold”, and keep that list in sync as SKUs are added, renamed and retired. That is manageable for one SKU and a maintenance nightmare across many. An edition collapses that whole list back into one stable code.
Reading the edition in your application
After a successful activation or validation, the edition code is available from the license. In the C++ SDK:
std::string version = pValidator->getVersion(); // e.g. "gold"
if (version == "gold") {
// unlock Gold features
}
The same code is returned in the REST API as version_code on the validate response, so server-side and online flows can branch on it too. Because the code is fixed, the same binary handles every edition — you ship once and let the license decide what to turn on.
Related
- Versions (dashboard) — creating and editing versions in the UI
- SKUs — a version is attached where a product meets a SKU
- Products — assigning versions to a product
- Upgrades — moving a customer from one edition to another