Dynamic values
How to leverage dynamic values for a rule's conditions.
The value key of a condition can be dynamic — useful when the value to be compared against the field isn't known in advance, or depends on another field in the payload.
To leverage dynamic values for a rule's conditions, you need to wrap the reference field in double curly brackets: {{<reference_field>}} where <reference_field> is the resource's field (expressed in dot notation) that will be used as a variable to calculate the value. You can also apply some basic aggregation operators to the reference field (as shown in the examples below):
min
The smallest of the reference field values is used as the condition's value.
"{{min(order.line_items.shipment.available_shipping_methods.price_amount_cents)}}"
max
The biggest of the reference field values is used as the condition's value.
"{{max(order.line_items.compare_at_amount_cents)}}"
avg
The average of the reference field values is used as the condition's value.
"{{avg(order.line_items.sku.inventory.levels.quantity)}}"
The reference field type must be consistent with the matcher used against the field and value. Given the currently available functions, if you want to add one of the operators above, the reference field type must be numeric.
Examples
Direct dynamic value
The following condition uses a dynamic value to check if an order's line items have the same unit amount and compare-at amount (i.e. the actual selling price is equal to the full price displayed to the customer with a strikethrough — meaning the item is not on sale):
"conditions": [
{
"field": "order.line_items.unit_amount_cents",
"matcher": "eq",
"value": "{{order.line_items.compare_at_amount_cents}}"
}
]Dynamic value with operator
The following condition uses a dynamic value with the min operator to target the shipment line items associated with the cheapest shipping method among the ones available for an order's shipments:
Date-based values
Dynamic values also support date expressions, making it straightforward to write conditions that are evaluated against the current date or against a date field from the payload. This is particularly useful for time-sensitive promotions — such as birthday discounts, seasonal offers, or deals tied to specific order timestamps — without hard-coding any dates in your rules.
Date expressions follow the same double curly brackets {{...}} notation. The available functions accept a <date> argument and optionally an <interval>:
today
The current date (UTC), resolved once per rule evaluation. It's a costant, no additional argument accepted.
"{{today}}"
day(<date>)
The day of the month (1 – 31) extracted from <date>. When used as a value, the engine compares the day part of the field date against this number.
"{{day(today)}}"
month(<date>)
The month (1 – 12) extracted from <date>. When used as a value, the engine compares the month part of the field date against this number.
"{{month(order.updated_at)}}"
year(<date>)
The year extracted from <date>. When used as a value, the engine compares the year part of the field date against this number.
"{{year(today)}}"
{{birthday}}
Matches any date whose day and month equal today's, regardless of year. A year-agnostic shorthand for combining {{day(today)}} and {{month(today)}} in a single expression.
"{{birthday}}"
{{range(<date>, <interval>)}}
Defines a date window of ±<interval> around <date>. Learn more here.
"{{range(today, 7.days)}}"
The <date> argument can be either:
A constant —
today, which resolves to the current date (UTC) at evaluation time.A payload field path — any date or datetime field from the current payload, expressed in dot notation (e.g. current order's timestamps such as
order.created_at,order.updated_atetc.). The value is resolved per subject from the payload.
Even if all date expressions operate on field values of type Datetime, when a date-part function is used as the value (e.g. {{month(today)}}), the engine automatically extracts the same part from the field date before comparing — no additional operator is needed on the field side.
Date ranges
The range(<date>, <interval>) expression resolves to a pair of dates representing a symmetric window centered on <date>:
Because the value is an array of two dates, it must always be used with the gteq_lteq matcher, which checks that the field date falls within the range (inclusive on both ends).
The <interval> must follow the format n.<unit>, where n is a positive integer and <unit> is one of days, months, or years. For example:
{{range(order.updated_at, 7.days)}}— 7-day window around the order's latest update{{range(today, 2.months)}}— from 2months ago to 2 months from now{{range(today, 1.year)}}— from 1 year ago to 1 year from now
Examples
Birthday month discount
The following condition lets you apply a promotion to all customers whose birthday falls in the current month by comparing the month of the birthdate field in the customer's metadata with the current month (i.e. the engine extracts the month from customer.metadata.birthdate and checks whether it equals the current month as integers):
Birthday discount (exact day and month)
You can activate a promotion on a customer's actual birthday by combining two conditions:
To do that, you can also leverage the birthday shorthand:
Promotion for orders created in a specific date range
The following condition lets you activate a promotion for orders created within a 15-day window around the current date:
Match birthdate month with the order creatiom month
The following condition lets you apply a discount when the customer's birth month coincides with the month in which the order was created (i.e. the engine extracts the month from both the field date and the value expression, then compares them as integers):
Last updated