Management API
Order

Create Order

16min
POST
Request
Body Parameters
id
String
required
Order ID. This is a unique identifier for an order within a company
is_bundle
Boolean
optional
If true, defines the order as a bundle order. Defaults to false. For more details on bundle orders, see the Bundle section below
append
Boolean
optional
If set to true and order ID already exists, licenses (items) sent will be appended to the existing order. If set to false and order ID already exists, an error will be returned. If not set defaults to false.
is_test
Boolean
optional
Whether or not this is a test order
created
String
optional
Date and time order is created
order_type
String
optional
Current possible value is: normal
language
String
optional
Order language, value should be language short code
campaign_params
String
optional
e.g. Google campaign params for the order
download_id
String
optional
Custom order download ID
prevent_vm
String
optional
If set to true, license activation won't be possible on a Virtual Machine
metadata
String
optional
Custom metadata, in the format of a serialized JSON object
items
Object
required
Product licenses in this order
customer
Object
optional
Customer data for the order
customer_account_id
Number
optional
Assignes the order to a Customer Account. If the provided Customer is already assigned to a Customer Account, you can omit this value
add_to_customer_account
Boolean
optional
Determines whether the Order will be assigned to a Customer Account (defaults to `true`). If you're providing a Customer who is assigned to a Customer Account, but do not wish the Order to be automatically assigned to that same Customer Account, set this parameter to false
JSON
Responses
200


Metadata should be in literal string format, e.g: "metadata": "{ \"some_key\": \"some_value\" }"

Request

The id property in the request is a client-generated unique identifier for the request, such as a uuid string

Non-Bundle Order Request

TypeScript
JSON Schema
Example: Key-based license
Example: User-based license


Bundle Order Request

TypeScript
JSON Schema
Example: Key-based bundle
Example: User-based bundle


Response

Non-Bundle Order Response

TypeScript
JSON Schema
Example response


Bundle Order Response

TypeScript
JSON Schema
Example response


Licenses

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:

Key-based license order
User-based license order


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:

JSON


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.

Authorization methods: Key-based vs. User-based licenses

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.

Additional license properties

  • 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

Bundle Product Orders

LicenseSpring allows for products to be bundled, and the two types of products discussed in this article respective to bundling are:

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:

Bundle of key-based licenses
Bundle of user-based licenses


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