Create Order
Metadata should be in literal string format, e.g: "metadata": "{ \"some_key\": \"some_value\" }"
The id property in the request is a client-generated unique identifier for the request, such as a uuid string
Each entry in the items array specifies a product code and a list of licenses being associated to that product. The following examples show a minimal order request payload for key-based and user-based licenses:
For each license you can specify a policy_code within the license object which will assign properties to a license based on the specified License Policy. (For more details on these properties, see the next section). If no policy code is specified, the default license policy defined for the Product will be used.
You can also explicitly specify license properties which will override the License Policy values. For example:
In the above example, all License properties for the created license will be taken from the License Policy "policy_A", with the exception of the max_activations property which was explicitly specified in the order request payload.
Each product you create in the system allows for one of two possible license authorization methods:
- Key-based: clients interacting with the license are required to provide a license key in their request
- User-based: clients interacting with the license are required to provide user credentials in their request
When sending an order creation request, the authorization method of licenses in the request are determined by each license's product.
- When creating key-based licenses in an order, you can provide a license key in the key property of the license. This is optional, and if omitted our system will generate a unique license key which will be returned to you in the order creation response object.
- When creating user-based licenses in an order, you must specify the users (1 or more) attached to that license by specifying them in a list in the users property of the license.
- max_activations - maximum number of time this license can be activated. If not set, product max activations is being used if defined for the product, if not - default value of 1 activation is being used.
- license_type - type of license - value can be either time-limited, perpetual consumption or subscription. If it is a time limited license, valid_duration should also be set for the license. If it is perpetual license then valid duration does not apply and if consumption, max_consumptions is being used and should be set in order, if not, product max consumptions is being used.
For subscription licenses, LicenseSpring requires an integration to an external source of truth (like a recurring billing system). LicenseSpring updates the status of the license according to the status of the subscription, which is handled by a 3rd party. Without this integration, subscription licenses remain valid until otherwise specified
- max_consumptions - used in pair with consumption license_type - defines how many times product can be used within the license.
- valid_duration - defines how long license should be valid - value examples: 1y (one year) or 2m (2 months) or 3d (3 days) or 4h (4 hours) or 5min (5 minutes).
- enable_maintenance_duration - whether license should consider maintenance duration, used in pair with maintenance_duration.
- start_date - start date of license "2024-03-12"
- maintenance_duration - duration of license maintenance period - value examples: 1y (one year) or 2m (2 months) or 3d (3 days).
- validity_period - final end date and time license is valid.
- product_features - array of additional product features
- shorter version with product feature code only: ["feature1", "feature2"]
- longer version, suitable for consumption features: [{code: "feature_code", max_consumption:33}].
- is_trial - boolean, defaults to False - whether this is a trial license or not.
- prevent_vm - boolean, defaults to False - whether license should be allowed on virtual machines.
- max_transfers - integer, defaults to 0 (Device transfer not allowed) - limit of license transfers between different devices.
For user-based licenses, instead of a license key, user is assigned as an object:
- email - required, email of the license user
- is_manager - optional (default false), if this user is license manager for all licenses in this order
Only for consumption licenses:
- allow_overages - boolean, defaults to False - whether license should allow overage license usage regardless the consumption, value example: true or false
- max_overages - number, maximum overage of consumption over the max_consumption.
- reset_consumption - boolean, defaults to False, whether license consumption my be reset, value example: true or false
- consumption_period - period over which licenses are reset - week, month or year
LicenseSpring allows for products to be bundled, and the two types of products discussed in this article respective to bundling are:
- Non-bundle products (default) - these are singular products where each license is attached to one product. Clients interacting with these licenses use the following endpoints on the License API:
- Bundle products - these are products that contain multiple products within. The system creates a license for both the bundle itself and the products contained in the bundle. Activating/deactivating the top-level bundle license also activates/deactivates the licenses included within the bundle. Clients interacting with these licenses use the following endpoints on the License API:
A Bundle Order contains multiple products linked to a single Bundle Product. To create a Bundle Order, you have to set the is_bundle property, and the products within the bundle are explicitly specified within each License object, as in the following examples:
For Bundle Orders, the policy_code property is mandatory
For Bundle Orders, the policy_code property has an alternate name: license_template_code. Both function identically, though the license_template_code name is considered deprecated on the API




