Create Order

URL : /api/v1/orders/create_order/

Method : POST

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 - Boolean

    • 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 - Array of Objects

    • each object can contain

      • product_code - String

        • required

        • Product code to identify the product license order is being created for

      • licenses - Array

        • A list of license definitions for this order. See the Licenses section below for more details

      • note - String

        • optional

  • customer - Object

    • can contain

      • email - String

        • optional

        • customer's email address

      • first_name - String

        • optional

        • customer's first name

      • last_name - String

        • optional

        • customer's last name

      • company - String

        • optional

        • customer's company name

      • phone - String

        • optional

        • customer's phone number

      • address - String

        • optional

        • customer's address

      • reference - String

        • optional

        • customer's custom reference. This can be any identifier for the customer in your system like an UUID.

      • is_manager - Boolean

        • optional

        • if true, customer will be set as manager of licenses in this order

  • customer_account_id - Integer

    • 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

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 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).

  • 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 as an object with the code property 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 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 - weekly, monthly or annually

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

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?