The strategy used for authenticating as a license, for client-side integrations. ### Options - TOKEN: Allow licenses to authenticate using a license token. This is the default. - LICENSE: Allow licenses to authenticate using a license key. - MIXED: Allow both license token and license key authentication (each covered above). - NONE: Disable the ability for licenses to authenticate with the API.
One of day, week, month or year. The frequency at which a license should check-in. ### Options - day: Require a license implementing the policy to check-in at least once every day to remain valid. - week: Require a license implementing the policy to check-in at least once every week to remain valid. - month: Require a license implementing the policy to check-in at least once every month to remain valid. - year: Require a license implementing the policy to check-in at least once every year to remain valid.
The number of intervals (specified in the check-in interval property) between each required check-in. For example, checkInInterval=week and checkInIntervalCount=2 requires check-in every 2 weeks. Must be a number between 1 and 365 inclusive.
The duration for the policy in seconds. When a new license implements the policy, the license's expiry is calculated with this value (i.e. time.now + policy.duration). If null, licenses will never expire.
The strategy for expired licenses during a license validation and when accessing releases. ### Options - RESTRICT_ACCESS: Expired licenses can continue to access releases published prior to their expiry, but automatic upgrades are disabled. Validation scopes take precedence over expiry check during license validation. - REVOKE_ACCESS: Expired licenses are no longer able to access any releases, including past releases and upgrades. Expiry check takes precedence over scopes during license validation. - MAINTAIN_ACCESS: Expired licenses can continue to access releases published prior to their expiry, but automatic upgrades are disabled. Validation scopes take precedence over expiry check during license validation. In addition, validations with an EXPIRED code will return valid=true. - ALLOW_ACCESS: Expired licenses can access any releases, including past releases and future automatic upgrades. Validation scopes take precedence over expiry check during license validation. In addition, validations with an EXPIRED code will return valid=true.
When enabled, a license that implements the policy will be valid across multiple machines. Though this is not enforced i.e. it does not invalidate a license if it's associated with more than 1 machine unless the policy is strict.
Control when a machine's initial heartbeat is started. By default, a machine's heartbeat is started on creation when its policy requires a heartbeat. Otherwise, it is started on first ping. ### Options - FROM_CREATION: The heartbeat duration is calculated from the machine's creation time. - FROM_FIRST_PING: The heartbeat duration is calculated from the machine's first heartbeat ping.
The strategy used for culling dead machines and processes. ### Options - DEACTIVATE_DEAD: Automatically deactivate machines that fail to maintain their heartbeat pings. This is the default. - KEEP_DEAD: Mark machines that fail to maintain their heartbeat pings as dead, but do not deactivate.
The heartbeat duration for the policy, in seconds. When a machine has an active heartbeat monitor, the machine must send heartbeat pings within this timeframe to remain activated. Must be greater than or equal to 1 minute (60).
The strategy used for controlling whether or not dead machines and processes can be resurrected shortly after death. A resurrection occurs when a heartbeat ping is sent to a dead machine or process that is within its resurrection window. ### Options - NO_REVIVE: Do not allow dead machines and processes to be revived. This is the default. - 1_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 1 minute from its time of death. - 2_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 2 minutes from its time of death. - 5_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 5 minutes from its time of death. - 10_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 10 minutes from its time of death. - 15_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 15 minutes from its time of death. - ALWAYS_REVIVE: A machine or process can always be revived. Requires a cull strategy of KEEP_DEAD.
The strategy used for leasing machines. ### Options - PER_LICENSE: Machine processes are counted per-license, i.e. collectively across all of a license's machines. - PER_USER: Machines are counted per-user, per-license. For example, with a max machines value of 2, each user could have 2 machines per-license.
The matching strategy for machine fingerprints supplied during a license validation. ### Options - MATCH_ANY: At least 1 of the supplied fingerprints must match a fingerprint for the license's associated machines. E.g. if 3 fingerprints are supplied, at least 1 of them must match. - MATCH_TWO: At least 2 of the supplied fingerprints must match a fingerprint for the license's associated machines. E.g. if 4 fingerprints are supplied, at least 2 of them must match. - MATCH_MOST: The majority of supplied fingerprints must match the fingerprints for the license's associated machines. E.g. if 3 fingerprints are supplied, at least 2 of them must match. - MATCH_ALL: All supplied fingerprints must match the fingerprints for the license's associated machines. E.g. if 3 fingerprints are supplied, all 3 of them must match.
The matching strategy for machine fingerprints supplied during a license validation. ### Options - UNIQUE_PER_ACCOUNT: Machine fingerprints must be unique across the entire Keygen account. This will block all duplicate fingerprints, regardless of whether or not the fingerprint belongs to another product, policy or license. - UNIQUE_PER_PRODUCT: Machine fingerprints must be unique across all licenses belonging to a product. This will block all duplicate fingerprints of the same product, regardless of whether or not the fingerprint belongs to another policy or license. - UNIQUE_PER_POLICY: Machine fingerprints must be unique across all licenses for the policy. This will block all duplicate fingerprints of the same policy, regardless of whether or not the fingerprint belongs to another license. - UNIQUE_PER_LICENSE: Machine fingerprints must be unique to the license. This will block all duplicate fingerprints for same license, but the same fingerprint can exist across different licenses. This is the default.
The maximum number of machine CPU cores a license implementing the policy can have associated with it. The count is the sum of all cores for the license's machines. This is inherited from the policy. When null, a license which implements the policy can have an unlimited number of CPU cores.
The maximum number of machines a license implementing the policy can have associated with it. This is only enforced when the policy is strict. When null, an unlimited number of machines may be associated with a license if the policy is floating. Must be a number greater than 0, and must be equal to 1 for non-floating policies.
The maximum number of machine processes a license implementing the policy can have associated with it, also depending on the policy's leasing strategy. When null, an unlimited number of machine processes may be associated with a license. Must be a number greater than 0.
The maximum number of uses a license implementing the policy can have. Cannot exceed 2,147,483,647, which is the maximum value of a 4 byte integer. When null, a license which implements the policy can have an unlimited number of uses. This attribute is not taken into account during license validation. See the license's usage-related actions for more details.
The strategy used for allowing machine, core and process overages. Set to NO_OVERAGE to disable overages altogether (attempts to exceed a limit will then result in an error). ### Options - ALWAYS_ALLOW_OVERAGE: The license may exceed its limits, and doing so will not effect the licenses validity, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. - ALLOW_1_25X_OVERAGE: The license may exceed its limits, up to a maximum of 1.25x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 1.25x allowance has been exceeded. When using a 1.25x allowance, all resource limits must be divisible by 4. - ALLOW_1_5X_OVERAGE: The license may exceed its limits, up to a maximum of 1.5x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 1.5x allowance has been exceeded. When using a 1.5x allowance, all resource limits must be divisible by 2. - ALLOW_2X_OVERAGE: The license may exceed its limits, up to a maximum of 2x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 2x allowance has been exceeded. - NO_OVERAGE: Do not allow overages. Attempts to exceed limits will fail. This is the default.
The strategy used for leasing machine processes. ### Options - PER_MACHINE: Processes are counted per-machine. For example, given a policy with a max processes value of 5, each license could have up to 5 processes for each machine. This is the default. - PER_LICENSE: Processes are counted per-license. For example, with a max processes value of 5, each license could have up to 5 processes combined across all machines. - PER_USER: Processes are counted per-user, per-license. For example, with a max processes value of 5, each user could have up to 5 processes combined across all owned machines per-license.
Whether or not the policy is protected. A protected policy disallows users the ability to create and manage licenses themselves, useful in situations where Keygen is only managed server-side or when you aren't listening for the appropriate user-initiated webhook events. If the account is protected, all policies automatically inherit that value when left blank.
When enabled, a license that implements the policy will require check-in at a predefined interval to continue to pass validation i.e. if a license misses a check-in, it will be invalidated.
When enabled, validating a license that implements the policy will require a checksum scope to be provided, matching an accessible artifact for the license.
When enabled, validating a license that implements the policy will require a fingerprint scope that matches at least 1 of the license's machine relationships by its fingerprint.
Whether or not the policy requires its machines to maintain a heartbeat. When enabled, machines that do not have a heartbeat will fail validation with a HEARTBEAT_NOT_STARTED validation code. In addition, when enabled, new machines will automatically have their first heartbeat set upon creation. When disabled, heartbeats are optional.
When enabled, validating a license that implements the policy will require a machine scope that matches at least 1 of the license's machine relationships by its identifier (UUID).
When enabled, validating a license that implements the policy will require a policy scope that matches the license's policy relationship by its identifier (UUID).
When enabled, validating a license that implements the policy will require a product scope that matches the license's product relationship by its identifier (UUID).
When enabled, validating a license that implements the policy will require a version scope to be provided, matching an accessible release for the license.
The cryptographic encryption/signature scheme used on license keys. Can be used to implement offline licensing by storing tamper-proof data within a license's key. When null or omitted, the license's key will be stored unchanged. ### Options - ED25519_SIGN: Sign license keys with your account's Ed25519 signing key, using elliptic curve cryptography and SHA512. The given license key data will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}. This is our recommended signing scheme, but it may not be supported in your preferred programming language. - **RSA_2048_PKCS1_PSS_SIGN_V2**: Sign license keys with your account's 2048-bit RSA private key using RSA PKCS1-PSS padding, with a SHA256 digest, max salt length, and a SHA256 MGF1. The provided embedded dataset will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}, resulting in the final key. This is our recommended RSA scheme, but it may not be supported in your preferred programming language. - **RSA_2048_PKCS1_SIGN_V2**: Sign license keys with your account's 2048-bit RSA private key using RSA PKCS1 v1.5 padding, with a SHA256 digest. The provided embedded dataset will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}, resulting in the final key. - **RSA_2048_PKCS1_ENCRYPT**: Encrypt license keys with your account's 2048-bit RSA private key using RSA PKCS1 v1.5 padding. The provided dataset will be encrypted using your account's private key and then base64url encoded, resulting in the final key. The key can be decrypted using your account's public key. The key must contain no more than 245 bytes (please note this is byte length not string length). - **RSA_2048_JWT_RS256**: Encode a license claims payload into a JWT using the RS256 algorithm. The license key must be a valid JWT claims payload (i.e. a JSON encoded string). The JWT will be signed using your account's 2048-bit RSA private key and can be verified using your account's public key. The resulting key will be a full JSON Web Token. We do not modify your claims payload.
When enabled, a license that implements the policy will be considered invalid if its machine limit, machine core limit, or processes limit is surpassed. In addition, strict requires a license to have at least 1 machine associated with it in order to pass validation.
Control whether a license's expiration is reset when transferred to this policy. ### Options - RESET_EXPIRY: Reset the transferred license's expiry from the time of transfer. For example, if the license had an expiry 3 months from now, and the new policy has a duration of 1 year, transferring would reset the expiry to 1 year from the time of transfer. When the policy has no duration, the license's expiry is removed. - KEEP_EXPIRY: Do not change the license's current expiry. This is the default.
Whether or not to pull license keys from a finite pool of pre-determined keys. This is useful for invite-only programs such as a private beta, when you need a limited set of licenses, or when you want to define the keys manually. This cannot be changed later on.
