Introducing our brand new event Stream Hub
Read the docs
Ctrlk
GitHubSign inSign up for free
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Rules

How rules are structured and what are the required and optional parameters to define a rule

Rules are defined within a JSON payload as an array of rule objects under the rules key. For each rule you must provide at least name, one or more conditions that have to be satisfied for the rule to match, and one or more actions that will be applied if the conditions are met:

{
  "rules": [
    {
      "name": "First rule",
      ...
      "conditions": [
        { ... },
        { ... }
      ],
      "actions": [
        { ... },
        { ... },
        { ... }
      ]
    },
    {
      "name": "Second rule",
      ...
      "conditions": [
        { ... },
        { ... },
        { ... }
      ],
      "actions": [
        { ... },
        { ... }
      ]
    },
    { ... }
  ]
}

Other optional rule's parameters (such as a unique identifier and the logic that you want to use to evaluate multiple rules) can be also specified:

Key
Type
Required
Description
Example

id

String

The rule's identifier (we recommend using UUIDs, if not specified will be automatically generated and added by the Core API integration).

"abcd-1234-xyzk-5678"

name

String

The rule's name (we recommend adding all essential information to help easily identify it among others).

"10% discount on tagged orders"

priority

Integer

The order in which the rules are evaluated (the lower the number, the higher the priority).

2

conditions_logic

String

The logic according to which the conditions are evaluated to determine the overall match. Can be one of and or or, default is and.

or

conditions

Array

The conditions that must be satisfied for the rule to match.

Learn more here.

actions

Array

The actions that will be applied if the conditions are met.

Learn more here.

In case of multiple rules, all and only the actions belonging to the matching rules will be applied. If no priority is defined, the rules are applied in the order that they are listed in the rules array (starting from priority 0).

For performance reasons, the maximum number of rules within a rules payload is 10.

Example

Let's consider a combination of rules that implements a quite complex promotional logic. Based on the order payload checked against them the rules application may result in different outcomes. Some of them are analyzed here below.

  1. The first rule contains two conditions and one action to apply a 2500 cents discount per unit to all the products in the order that costs more than 9900 cents if the order contains such kind of products and the total order's amount is at least 50000 cents.

  2. The second rule contains one condition and two actions to apply an additional 15% discount on all the products in the order and offer free shipping if the email address of the customer who placed the order belongs to a specified domain.

All rules match

This order contains at least one SKU that costs more than 9900 cents, the order total amount is greater than or equal to 50000 cents, and the associated customer email matches the specified domain:

Both rules match and all the three actions will be applied, meaning that:

  • The identified discountable items will be discounted by 2500 cents per unit based on the first rule. An additional 15% discount due to the second rule will be also applied to those items.

  • All the other line items in the order associated with an SKU (if any) will be discounted by 15%.

  • All the shipment costs will be zeroed by applying a 100% percentage discount.

As you can see, since no priority was defined at the rules level, the priority attribute in the results follows the default behavior and matches the order in which the rules are listed in the original rules payload.

Only the first rule matches

This order contains at least one SKU that costs more than 9900 cents, the order total amount is greater than or equal to 50000 cents, but the associated customer email doesn't match the specified domain:

Only the first rule matches, meaning that:

  • The identified discountable items will be discounted by 2500 cents per unit.

  • No other additional discount will be applied.

As you can see, the second rule's actions array is empty, which implies that the rule triggers no action since the related condition's matches array is empty (meaning that the condition is not satisfied).

Only the second rule matches

The customer email associated to this order matches the specified domain, the order contains at least one SKU that costs more than 9900 cents but the order total amount is lower than 50000 cents:

Only the second rule matches, meaning that:

  • All the line items in the order associated with an SKU will be discounted by 15%.

  • All the shipment costs will be zeroed by applying a 100% percentage discount.

As you can see, the first rule's actions array is empty, which implies that the rule triggers no action since one of the related conditions' matches array is empty (meaning that the overall combination of conditions is not satisfied).

No rules match

The customer email associated with this order doesn't match the specified domain, the order total amount is greater than or equal to 50000 cents but the order doesn't contain at least one SKU that costs more than 9900 cents:

None of the two rules matches, so no discount will be applied.

As you can see, both rules' actions array is empty, which implies that they trigger no action since the related conditions' matches arrays are empty (meaning that the conditions are not satisfied).

Keep reading to learn more about how to set conditions and actions for a a rule or feel free to browse the use cases section to check more examples of rules based on real ecommerce scenarios.

Use cases
PreviousGetting startedNextConditions

Last updated