Create Order
URL : /api/v1/orders/create_order/
Method : POST
Parameters
id- Stringrequired
Order ID. This is a unique identifier for an order within a company
is_bundle- Booleanoptional
If true, defines the order as a bundle order. Defaults to false. For more details on bundle orders, see the Bundle section below
append- Booleanoptional
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- Booleanoptional
Whether or not this is a test order
created- Stringoptional
Date and time order is created
order_type- Stringoptional
Current possible value is: normal
language- Stringoptional
Order language, value should be language short code
campaign_params- Stringoptional
e.g. Google campaign params for the order
download_id- Stringoptional
Custom order download ID
prevent_vm- Booleanoptional
If set to true, license activation won't be possible on a Virtual Machine
metadata- Stringoptional
Custom metadata, in the format of a serialized JSON object
items- Array of Objectseach object can contain
product_code- Stringrequired
Product code to identify the product license order is being created for
licenses- ArrayA list of license definitions for this order. See the Licenses section below for more details
note- Stringoptional
customer- Objectcan contain
email- Stringoptional
customer's email address
first_name- Stringoptional
customer's first name
last_name- Stringoptional
customer's last name
company- Stringoptional
customer's company name
phone- Stringoptional
customer's phone number
address- Stringoptional
customer's address
reference- Stringoptional
customer's custom reference. This can be any identifier for the customer in your system like an UUID.
is_manager- Booleanoptional
if true, customer will be set as manager of licenses in this order
customer_account_id- Integeroptional
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- Booleanoptional
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
Notes
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.
If append is set to true and no order with the given ID exists, a new order will be created.
Request
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
Notes overview
Global note → applied to all licenses
License-level note → applies only to that license
Both → license-level note takes priority
None → no note field included
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
License Policy
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.
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
keyproperty 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
usersproperty 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 licensevalue 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 consumptionlicense_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) or2m(2 months) or3d(3 days) or4h(4 hours).enable_maintenance_duration- whether license should consider maintenance duration, used in pair withmaintenance_duration.start_date- start date of license"2024-03-12"maintenance_duration- duration of license maintenance period - value examples:1y(one year) or2m(2 months) or3d(3 days).validity_period- final end date and time license is valid.product_features- array of additional product featuresshorter version with product feature code only:
["feature1", "feature2"]longer version as an object with the
codeproperty and any additional property as an overrided value, eg:[{ "code": "feature_code", "max_consumption": 33, "expiry_date": "2027-05-23" }]. For a full definition of this object see ProductFeature in the Request definition above
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 useris_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:trueorfalsemax_overages- number, maximum overage of consumption over themax_consumption.reset_consumption- boolean, defaults to False, whether license consumption my be reset, value example:trueorfalseconsumption_period- period over which licenses are reset -weekly,monthlyorannually
Bundle Product Orders
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:
Bundle of key-based licenses
Bundle of user-based licenses
Notes
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.
Last updated
Was this helpful?