License Key Architecture: A Developer's Guide to qPapel Key Generation
Home/Blog/License Key Architecture: A Developer's Guide to qPapel Key Generation
Developer GuideApril 5, 202610 min read

License Key Architecture: A Developer's Guide to qPapel Key Generation

PapelShip TeamPapelShip Team
qPapel Licence ManagementDeveloper GuideLicense KeysHWID

Understanding qPapel License Key Types

Every software product shipped through PapelShip can leverage the qPapel Protection engine for license management. The key creation system at /dashboard/keys/create supports five distinct key archetypes, each designed for a different monetization model.

Key Types Explained

Single-Use Keys

A single-use key can be activated exactly once. After the end-user validates their license through the qPapel API, the key is consumed and cannot be used again. This is ideal for one-time digital product deliveries like game keys, serial codes, or downloadable assets.

Multi-Use Keys

Multi-use keys allow a configurable number of activations via the max_uses parameter. For example, a team license with max_uses: 5 lets five different machines activate the same key. The used_count field tracks how many activations have been consumed.

Time-Limited Keys

Time-limited keys bind to a duration in days. When a user first activates the license, the system records start_time and calculates end_time by adding the configured duration_days. The dashboard shows remaining time in a human-readable format like "14d 6h left".

Hour-Limited Keys

Similar to time-limited keys, but measured in hours instead of days. Perfect for trial periods, pay-per-hour access models, or competitive gaming sessions where access is measured in short bursts.

Demo Keys

Demo keys (is_demo: true) are special keys that grant limited access without consuming a paid license slot. They're useful for reviewers, testers, or promotional campaigns.

Hardware ID (HWID) Binding

When bind_hwid is enabled on a key, the first activation records the client machine's hardware fingerprint in the hwid_value column. All subsequent validation requests must present the same HWID or they will be rejected.

The HWID method is configured per-product in the Remote Settings panel and supports four fingerprinting strategies:

MethodIdentifier SourceSpoofing Difficulty
CPUCPU Serial NumberModerate
MACNetwork Adapter MACEasy (VPN changes)
DiskHDD/SSD Serial NumberHard
Windows GUIDRegistry MachineGUIDEasy (regedit)

For maximum security, we recommend CPU or Disk methods. HWID resets can be performed from the key management dashboard — you can reset individually or bulk-reset all keys using the "Reset All HWID" action.

Bulk Operations

The keys dashboard supports powerful bulk operations:

  • Select Mode — Toggle checkbox selection on all visible keys
  • Add Time All — Extend expiration for every active key by a configurable amount (hours, days, or weeks)
  • Bulk Add Time — Add time only to selected keys
  • Bulk Ban / Unban — Mass-ban or mass-unban selected keys
  • Bulk Delete — Permanently remove selected keys (requires confirmation)

Reseller System

Keys can be delegated to resellers via the reseller_id field. The scope filter lets you view:

  • My Keys (scope=me) — Only keys you created
  • Reseller Keys (scope=resellers) — Keys created by your resellers
  • All (scope=all) — Combined view

Each key stores its creator and creator_ip for audit purposes. Resellers can only manage keys assigned to their accounts and products they've been granted access to.

Key Lifecycle Flow

1.Creation — Key generated at /dashboard/keys/create with type, product binding, and optional HWID enforcement
2.Waiting — Key exists but hasn't been activated (used_count = 0)
3.Active — User validated the key; start_time recorded, HWID locked if enabled
4.Expiredend_time has passed (time-limited/hour-limited only)
5.Banned — Manually or automatically banned; is_banned = true with optional note for reason

API Validation Endpoint

Your client application validates licenses by hitting the qPapel API. The typical request flow:

1.Client sends key_value, product (cheat_value), and collected hwid
2.Server verifies key exists, is active, not banned, not expired
3.If bind_hwid is enabled and hwid_value is null → records the HWID
4.If bind_hwid is enabled and hwid_value doesn't match → rejects
5.Returns license metadata (remaining time, max uses, status)

Start building your license system today. Create your first key →

More from the blog