Guide: Reading from GET · ← Conditions · Effects →

rule_application — complete reference

:::info Field in the GET response In GET /points and GET /points/{id}, this block is returned in **rule_application** (JSON string). After parsing, the internal root is **application.and[]** (not conditions). :::

On this page

• What it does (and what it does not)
• Application by when
• Custom event application
• Application on payment methods (cart only)
• Empty vs defined
• Typical case: no win conditions, application only
• Two application families
• Nested subconditions on lines: quantity only
• Grammar shared with line conditions
• Bundle / 2x1: quantity in application
• Application on additional_costs
• Master reference JSON — line application
• Win conditions + different application (common case)
• Mandatory application (percentage / ratio)
• Common mistakes — rule_application

---

What it does (and what it does not)

Block	Question it answers
**rule_conditions**	When can the campaign come into play? (eligibility: customer, cart, lines, thresholds, …)
**rule_application**	Where is the accrual applied if the campaign applies? (ticket lines and/or a specific additional cost)

rule_application does not replace win conditions: it scopes the effect. It reuses grammar similar to line conditions (conditions.and, array_field: lines, field, values, …) and also supports application on a field under the ticket’s **additional_costs**.

Application by when

when	rule_application
Cart (after_create_activity)	Lines (array_field: lines), product by ID/code, categories, line attributes, additional_costs.*, and payment methods (array_field: payments, field: type, values, payment_method_ids) — see Application on payment methods. In the discounts integration guide, payment often appears only in conditions; for points on cart it can also appear in application.
Custom event (after_create_custom_entity)	A single numeric custom-entity attribute the effect is calculated on — see Custom event application.
Trigger / Manual	No application block in Owner App (no cart lines).

Custom event application

For campaigns with when: "after_create_custom_entity", Owner App does not use product catalog or cart lines. In rule_application you choose one custom-entity field that drives the effect (percentage, ratio, or direct_value with distribution: "total").

field rule: in key: "custom_event" clauses, field is always data. + the attribute name from the event definition (e.g. attribute amount → "field": "data.amount"). Never use the bare attribute name in field.

Rule	Detail
Field type	Numeric attributes only (e.g. amount, quantity).
field	Always data.<attribute_name> (e.g. data.amount).
entity_attribute_key	Attribute slug without the data. prefix (e.g. "amount").
Typical operator in application	exists — declares which numeric field feeds the calculation (thresholds belong in rule_conditions).

Example: application uses field amount. Effect is ratio with unit: 1 and value: 0.01 (monetary amount in DB; with score_exchange 0.01 → 1 unit of amount = 10 points shown to the customer). See monetary value.

rule_application (string in GET):

{
  "conditions": {
    "and": [
      {
        "key": "custom_event",
        "field": "data.amount",
        "operator": "exists",
        "entity_attribute_key": "amount"
      }
    ]
  }
}

Associated rule_effects:

{
  "key": "ratio",
  "type": "ratio",
  "unit": 1,
  "value": 0.01,
  "limits": 0,
  "formula": null,
  "distribution": "total",
  "strikethrough_data": null
}

For custom events, rule_application JSON may use root conditions.and[] (not application.and[] as on cart). Parse the string and find the custom_event clause.

Win conditions on other event fields (thresholds, text, etc.) belong in rule_conditions, not application.

Application on payment methods (cart only)

On cart campaigns, accrual can be scoped to lines paid with certain methods (same clause shape as payment conditions, but under application.and[]):

{
  "application": {
    "and": [
      {
        "array_field": "payments",
        "field": "type",
        "operator": "in",
        "values": ["card"]
      }
    ]
  }
}

Use payment_method_ids when filtering by specific method IDs configured in the Company.

Empty vs defined

rule_application state	Behavior
Empty / absent / null	The accrual may apply to all lines on the ticket (per rule_effects.distribution)
With filters	The accrual applies only where the rule indicates (lines and/or an additional_costs.name``)

Typical case: no win conditions, application only

For a campaign that must accrual certain products always (no cart threshold, no minimum qty in conditions, etc.):

1. Leave **rule_conditions empty** (no eligibility requirements).
2. Define only the target products (or categories) in **rule_application**.

Conceptual example:

{
  "rule_conditions": { "conditions": { "and": [] } },
  "rule_application": {
    "conditions": {
      "and": [
        {
          "array_field": "lines",
          "field": "product_id",
          "key": "cart_item_product",
          "operator": "in",
          "values": [10045, 10046]
        }
      ]
    }
  },
  "rule_effects": "{ ... percentage, distribution: individual_items ... }"
}

Interpretation: “The campaign does not require anything special to ‘win’; if it is active and the customer qualifies by audience/stackability, the % (or amount) applies only on lines with product_id 10045 or 10046.”

In GET /points and GET /points/{id}, rule_conditions and rule_application are returned as JSON strings; parse both separately.

Two application families

Family	How to identify it	What it scopes
Ticket lines	array_field: lines	Products, categories, line attributes
Additional cost	field: additional_costs.name``	A specific charge on the ticket’s additional_costs object (e.g. shipping)

Do not use customer conditions (customer.*), country, cart total, payments, etc. in application — those belong in rule_conditions.

Nested subconditions on lines: quantity only

Inside conditions[] on application clauses over lines, only quantity exists. You cannot choose line **total** (unlike rule_conditions, where total may appear).

Subcondition field	In rule_conditions	In rule_application
quantity	✓	✓
total	✓	Not available

Valid example in application:

"conditions": [{ "field": "quantity", "value": 1, "operator": "gte" }]

Grammar shared with line conditions

Concept	In rule_conditions	In rule_application
Catalog product	May require line qty and/or total	Defines which products the effect applies to; typical subcondition: quantity only
Manual product (cart_product_id)	Same	Same
Category (product_categories)	May require qty/total	Defines target categories; subcondition: quantity only
Line attributes	Win condition	Scopes application (no qty subcondition if not needed)

Reading rules (same as in conditions):

• **field** defines the data; **key** is informational.
• cart_item_product = catalog; cart_product_id = manual.
• Categories: values = feature_pk (taxonomy_slug|external_id).
• bundle / grouped: internal flags — ignore the flag value.

Bundle / 2x1: quantity in application

If rule_effects.rule_group is **true**, the **quantity** subcondition in **rule_application** defines how many units per group receive the effect (e.g. gte 1 = one accrualed unit per group formed in win conditions). See Bundle mechanics.

Application on additional_costs

You can indicate that the effect applies to one specific additional cost on the ticket (not a product line).

Field	Description
field	Path to the cost: additional_costs.key`` (e.g. additional_costs.delivery when the ticket has "delivery": 2.99 inside additional_costs)
operator / value	Comparison on that cost amount (e.g. gt + 0 → it exists and is > 0)
key	Often total_cart_without_additional_costs (informational); **field** takes precedence
additional_cost_id	Internal ID of the additional cost type (auxiliary; e.g. 34 = shipping in the Company)

Example — effect on shipping cost:

{
  "conditions": {
    "and": [
      {
        "key": "total_cart_without_additional_costs",
        "field": "additional_costs.delivery",
        "value": 0,
        "operator": "gt",
        "additional_cost_id": 34
      }
    ]
  }
}

Interpretation: the accrual/effect applies to the delivery component of the ticket’s additional_costs block (when its value is > 0), not to product lines.

Master reference JSON — line application

Real example with categories, products (catalog and manual), and line attributes:

{
  "conditions": {
    "and": [
      {
        "key": "cart_item_product_category",
        "field": "product_categories",
        "bundle": 1,
        "values": ["gaston_interno|106", "frutas|17852"],
        "grouped": true,
        "operator": "in",
        "conditions": [{ "field": "quantity", "value": 1, "operator": "gte" }],
        "array_field": "lines",
        "feature_ids": [17885, 17852]
      },
      {
        "key": "cart_item_product",
        "field": "product_code",
        "bundle": 1,
        "values": ["12000041", "camisetaGlobo", "croata_01", "croata_02", "undefined"],
        "grouped": true,
        "operator": "in",
        "conditions": [{ "field": "quantity", "value": 1, "operator": "gte" }],
        "array_field": "lines",
        "product_ids": ["1", "2", "4", "5", "6"]
      },
      {
        "key": "cart_product_id",
        "field": "product_code",
        "bundle": 1,
        "values": ["22333", "98999", "977788"],
        "grouped": true,
        "operator": "in",
        "conditions": [{ "field": "quantity", "value": 1, "operator": "gte" }],
        "array_field": "lines"
      },
      {
        "key": "cart_item_attributes",
        "field": "attributes.color",
        "value": "azul",
        "operator": "eq",
        "array_field": "lines"
      },
      {
        "key": "cart_item_attributes",
        "field": "attributes.product_condition",
        "value": "refurbished",
        "operator": "neq",
        "array_field": "lines"
      }
    ]
  }
}

Quick read of the master JSON (application)

#	field / context	Interpretation
1	lines → product_categories	Discount on lines in categories `gaston_interno
2	lines → product_code, catalog	Listed catalog codes; qty≥1
3	lines → product_code, manual	Manually entered codes (cart_product_id); qty≥1
4	lines → attributes.color	Only lines with color = azul
5	lines → attributes.product_condition	Excludes refurbished lines (neq)

Win conditions + different application (common case)

The campaign wins with one logic and the accrual lands on a subset of lines:

Block	Business example
rule_conditions	Cart ≥ €50 and at least 2 units of Coca-Cola
rule_application	The % only on lines in category Snacks

Integration: the ticket may meet conditions via Coca-Cola but the accrual in the response appears only on Snack lines that satisfy rule_application.

Mandatory application (percentage / ratio)

For cart **percentage** and **ratio** effects, application is usually required in Owner App (see Operational details §5). If it is missing and the effect is line-level %, check for incomplete configuration.

Common mistakes — rule_application

Confusion	How to resolve it
Condition vs application	rule_conditions = does the campaign apply? · rule_application = which lines get the accrual?
Copying customer conditions into application	Customer/cart go in rule_conditions; application = lines and/or additional_costs
Looking for total in application subcondition	In application only **quantity** exists in conditions[]; line total does not apply
Empty rule_conditions misread	Empty = no win filters, not “campaign disabled”
Discount not on expected product	Check field + values in application, not only win conditions
Confusing lines with additional_costs	array_field: lines = products; field: additional_costs.X = extra charge (shipping, etc.)
Same product in conditions and application	Valid: conditions require buying it; application limits where it is accrualed (may be same list or another)

---

---

Next: Effects (rule_effects)