> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voucherify.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Validation rule reference

> Learn about rules, limits, and budget constraints available in the Voucherify validation rule builder

This page describes rules that secure your campaigns from fraud and define specific buying conditions. These rules control how and when customers can redeem incentives (codes or promotion tiers) or earn loyalty points.

Read the [Create validation rules](/optimize/create-validation-rules) article to build and use your rules.

The rules are grouped into the following categories:

* Audience
* Products
* Prices and quantities
* Budget constraints
* Redemptions
* Metadata

<Info>
  Rules and limits depend on the selected context. Some rules are not available for specific campaign types or use cases.
</Info>

## Glossary

Read this glossary to learn Voucherify terminology required to work with validation rules.

<AccordionGroup>
  <Accordion title="Customer segment">
    [Customer segments](/prepare/customer-segments) group customers based on standard attributes (such as email or postal code) and custom attributes added as metadata.
  </Accordion>

  <Accordion title="Custom event">
    [Custom events](/prepare/custom-events) are external actions performed by customers that are tracked and sent to Voucherify using the API.
  </Accordion>

  <Accordion title="Earning rule">
    [An earning rule](/build/earning-rules) is a rule that defines how and when loyalty points are assigned to a customer's loyalty card.
  </Accordion>

  <Accordion title="Holder of the code">
    A customer becomes the holder of a unique code (a coupon, gift card, referral code, or loyalty card) once it has been assigned to them. Assigned codes are visible in the customer profile under the Wallet tab.
  </Accordion>

  <Accordion title="Metadata">
    Also known as custom attributes. [Metadata](/prepare/metadata) allows you to store custom key-value data on Voucherify objects such as customers, orders, redemptions, products, and events. Metadata is commonly used to build validation rules and for reporting.
  </Accordion>

  <Accordion title="Redeeming user">
    A redeeming user refers to a team member or affiliate invoking a redemption. Validation rules using redeeming users can restrict which project members are allowed to perform successful redemptions.
  </Accordion>

  <Accordion title="Redemption">
    [Redemption](/optimize/validations-and-redemptions) is a single use of a promo code or an in-cart discount. In loyalty programs, a redemption represents exchanging loyalty points for a reward.
  </Accordion>

  <Accordion title="Validation rule builder">
    The **Validation rule builder** is the interface used to create validation rules. The [Validation rule builder](/optimize/create-validation-rules) is available in the campaign manager and in the validation rules section of the Voucherify dashboard.
  </Accordion>
</AccordionGroup>

## Audience

Audience rules define conditions customers must meet to receive or redeem an incentive:

* **Customer segment**: Target or exclude specific customer segments.
* **Customer loyalty tier**: Target or exclude customers based on their loyalty tier.
* **Redemption only by code holder**: Restrict code usage to the customer to whom the code was published.

## Products

Product rules define validation based on the structure of the customer's order. You can further refine these rules using **subrules** related to order structure or order volume.

### Any order item

At least one item in the cart must match the defined criteria:

* **is**: Specified products or collections must be present in the cart.
* **from**: The matched products must also belong to a specified collection.

<Tip>
  <Badge color="green">Example</Badge>

  Both conditions work like this: "is" a t-shirt collection, "from" a summer clothing collection.
</Tip>

You can add subrules such as:

* **Subtotal of matched items**: Define the total amount of all items that meet criteria set with product filters.
* **Quantity of matched items**: Define the total number of all items that meet criteria set with product filters across all order lines.
* **Unit price of the matching order line**: Define the price of at least one matching order line.
* **Item quantity in the matching order line**: Define the required quantity for at least one matching order line.
* **Matching item metadata**: Define limits using order items metadata that need to be met by at least one order line item.

### Every order item

Every item in the cart must match the defined criteria:

* **is**: Specified products or collections must be present
* **from**: Matched products must also belong to a specified collection

You can add subrules such as:

* **Subtotal of matched items**: Define the total amount of all items that meet criteria set with product filters.
* **Quantity of matched items**: Define the total number of all items that meet criteria set with product filters across all order lines.
* **Unit price of the matching order line**: Define the required price of every order line.
* **Item quantity in the matching order line**: Define the required quantity in every order line.
* **Matching item metadata**: Define limits using order items metadata that need to be met by every order line item.

### None of the order items

Excludes the cart from validation if specified products or collections are present:

* **is**: Specified products or collections must be present
* **from**: Matched products must also belong to a specified collection

### Most expensive of the order items

Defines rules for the most expensive item in the cart or the most expensive item within a specific collection:

* **is**: Products or collections that must be the most expensive
* **from**: Collection from which the most expensive item is selected

You can add subrules such as:

* **Subtotal of matched items**: Define the total amount of all the qualified most expensive items.
* **Quantity of matched items**: Define the total count of all the qualified most expensive items.
* **Unit price of the matching order line**: Define the required price of each qualified most expensive item.
* **Items quantity in the matching order line**: Define the required quantity of each qualified most expensive item.
* **Matching item metadata**: Define limits using order items metadata that need to be met by each qualified most expensive item.

### Cheapest of the order items

Defines rules for the cheapest item in the cart or the cheapest item within a specific collection:

* **is**: Products or collections that must be the cheapest
* **from**: Collection from which the cheapest item is selected

You can add subrules such as:

* **Subtotal of matched items**: Define the total amount of all qualified cheapest items.
* **Quantity of matched items**: Define the total count of all qualified cheapest items.
* **Unit price of any matching order line**: Define the required price of each qualified cheapest item.
* **Items quantity in any matching order line**: Define the required quantity of each qualified cheapest item.
* **Metadata of matched items**: Define limits using order items metadata that need to be met by each qualified cheapest item.

## Prices and quantities

These rules define validation based on order value and pricing and item quantities:

* **Total amount before discounts**: Requires the cart value (at validation time, before applying the current incentive) to meet a specified threshold. This value may change depending on previously applied incentives.
* **Total amount after discounts**: Requires the cart value after applying the current incentive to meet a specified threshold. If applying the discount reduces the order total below the configured threshold, validation fails and the discount is not applied.
* **Initial amount**: Requires the original cart value (before any discounts or stacking adjustments) to meet a specified threshold. This value remains **constant** throughout stacking.
* **Items quantity**: Requires a minimum or maximum number of products in the cart.
* **Price of each item**: Requires every product in the cart to meet a specified price condition.
* **Price of any item**: Requires at least one product in the cart to meet a specified price condition.

### Amount rules: quick comparison

In stacking scenarios, some rules are evaluated against the **original cart value**, while others use the **current cart value at the moment of validation**. This difference can affect whether a promotion is applicable depending on the order in which incentives are applied.

| Rule                              | What it checks                     | Changes during stacking | When to use                                                                |
| --------------------------------- | ---------------------------------- | ----------------------- | -------------------------------------------------------------------------- |
| **Initial amount**                | Original cart value                | ❌ No                    | Ignore stacking order                                                      |
| **Total amount before discounts** | Cart value at validation time      | ✅ Yes                   | Depend on current cart value, after taking into account previous discounts |
| **Total amount after discounts**  | Cart value after applying discount | ✅ Yes                   | Enforce minimum after discount                                             |

**Total amount before discounts** depends on stacking order. If earlier incentives reduce the cart value, this rule may fail even if the original cart value meets the requirement.

<Tip>
  Use **Initial amount** when validation should be independent of stacking order.

  Use **Total amount before discounts** when validation should depend on the cart value at the moment the incentive is applied.
</Tip>

<Accordion title="Example: stacking impact">
  A cart has an initial value of **10.50**.

  A coupon has the following rules:

  * **Total amount before discounts > 10**
  * **Initial amount \< 11**

  A gift card reduces the cart value by **1.00**.

  **Scenario 1: Coupon applied first**

  * Cart at validation: **10.50**
  * Both rules pass → coupon is applicable

  **Scenario 2: Gift card applied first**

  * Cart after gift card: **9.50**
  * Coupon validation sees:
    * Initial amount = **10.50** ✅
    * Total amount before discounts = **9.50** ❌
  * Coupon is **not applicable**
</Accordion>

## Budget constraints

Budget constraints limit campaign usage and help prevent abuse. They can also affect the number of redemptions done by customers.

* **Total orders value**: Define the value of all orders made within the campaign. Once the limit is reached, customers cannot redeem incentives.
* **Total discounted amount**: Define the overall value of the discount that the customers can get by redeeming incentives from a particular campaign.
* **Total number of redemptions**: Define the total number of redemptions allowed per entire campaign (the sum of all redemptions made within the campaign).
* **Total number of redemptions per day**: Define the daily limit of redemptions allowed in the entire campaign for all customers. The day is a calendar day, for example 1 January 2025.
* **Total number of redemptions per week**: Define the weekly limit of redemptions allowed in the entire campaign for all customers. The first day of the week (Monday, Saturday, or Sunday) is defined in **Project settings** > Locale. For Monday, a week lasts between Monday 00:00 and the end of Sunday 23:59, for example between Monday 00:00 6 January 2026 and the end of Sunday 23:59 11 January 2026.
* **Total number of redemptions per month**: Define the monthly limit of redemptions allowed in the entire campaign for all customers. The month is a calendar month, for example January.
* **Redemptions per incentive per day**: Define the daily limit of redemptions for a given incentive (code or promotion tier). The day is a calendar day, for example 1 January 2025.
* **Redemptions per incentive per week**: Define the weekly limit of redemptions for a given incentive (code or promotion tier). The first day of the week (Monday, Saturday, or Sunday) is defined in **Project settings** > Locale. For Monday, a week lasts between Monday 00:00 and the end of Sunday 23:59, for example between Monday 00:00 5 January 2026 and the end of Sunday 23:59 11 January 2026.
* **Redemptions per incentive per month**: Define the monthly limit of redemptions for a given incentive (code or promotion tier). The month is a calendar month, for example January.
* **Redemptions per customer per incentive**: Define the total number of redemptions that a particular customer can make using a given incentive (code or promotion tier).
* **Redemptions per customer per incentive per day**: Define the daily limit of redemptions that a particular customer can make using a given incentive (code or promotion tier). The day is a calendar day, for example 1 January 2025.
* **Redemptions per customer per incentive per week**: Define the weekly limit of redemptions that a particular customer can make using a given incentive (code or promotion tier). The first day of the week (Monday, Saturday, or Sunday) is defined in **Project settings** > Locale. For Monday, a week lasts between Monday 00:00 and the end of Sunday 23:59, for example between Monday 00:00 5 January 2026 and the end of Sunday 23:59 11 January 2026.
* **Redemptions per customer per incentive per month**: Define the monthly (calendar month) limit of redemptions that a particular customer can make using a given incentive (code or promotion tier). The month is a calendar month, for example January.
* **Redemptions per customer in a campaign**: Define the total number of redemptions counted per customer per campaign.
* **Redemptions per customer in a campaign per day**: Define the daily limit of redemptions that a particular customer can make using incentives from a particular campaign. The day is a calendar day, for example 1 January 2025.
* **Redemptions per customer in a campaign per week**: Define the weekly limit of redemptions that a particular customer can make using incentives from a particular campaign. The first day of the week (Monday, Saturday, or Sunday) is defined in **Project settings** > Locale. For Monday, a week lasts between Monday 00:00 and the end of Sunday 23:59, for example between Monday 00:00 5 January 2026 and the end of Sunday 23:59 11 January 2026.
* **Redemptions per customer in a campaign per month**: Define the monthly (calendar month) limit of redemptions that a particular customer can make using incentives from a particular campaign. The month is a calendar month, for example January.
* **Total redeemed gift amount**: Define the total value of the redeemed balance in the whole campaign.
* **Maximum pay with points**: Define the number of loyalty points to be used to pay for an order.

<Warning>
  Once a budget limit is reached, customers can no longer redeem incentives from that campaign.
</Warning>

## Redemptions

Redemption rules define technical constraints on how redemptions are handled:

* **Redeeming user**: Restrict which team members or affiliates can invoke redemptions.
* **Redeeming API key**: Restrict redemption requests to specific API keys.
* **Redemption only by code holder**: Restrict redemptions to the customer the code was published to.

## Metadata

Metadata rules define validation based on custom attributes:

* **Customer metadata**: Require specific metadata to be present in the customer.
* **Order metadata**: Require specific metadata to be present in the order.
* **Redemption metadata**: Require specific metadata to be present in the redemption request.
* **Custom event metadata**: Require specific metadata to be present in custom events.

## Related features

Validation rules work with other Voucherify features. Use the resources below to prepare data for your rules.

<AccordionGroup>
  <Accordion title="Customer segments">
    [Customer segments](/prepare/customer-segments) group customers based on shared attributes or behavior. Use segments in **Audience** rules to target specific customer groups.

    Segments update dynamically, so a rule that targets a segment always checks the current membership.
  </Accordion>

  <Accordion title="Product collections">
    [Product collections](/prepare/product-collections) group products based on attributes or filters. Use collections in **Products** rules to define required or excluded cart items.

    Dynamic collections update automatically when products match the defined filters.
  </Accordion>

  <Accordion title="Metadata schemas">
    [Metadata](/prepare/metadata) lets you store custom attributes on customers, orders, products, and redemptions. Use metadata in validation rules to create conditions based on any custom data.

    Define metadata schemas in **Project Settings** to ensure consistent data types across rules.
  </Accordion>

  <Accordion title="Custom events">
    [Custom events](/prepare/custom-events) track customer actions sent via API. Use custom event metadata in validation rules for distributions or earning rules.

    For example, trigger a distribution only when a custom event includes specific metadata.
  </Accordion>

  <Accordion title="Campaigns and earning rules">
    Validation rules control eligibility for:

    * [Discount coupons](/build/create-discount-coupons) and [promotions](/build/create-discount-promotions)
    * [Loyalty earning rules](/build/earning-rules)
    * [Referral campaigns](/build/create-referral-campaign)

    Each campaign type supports different rule categories based on its context.
  </Accordion>

  <Accordion title="Developer setup: Validation Rules API">
    Developers can manage validation rules using the [Validation Rules API](/api-reference/validation-rules/validation-rule-object).

    The API supports creating rules, assigning them to campaigns, and listing all assignments.

    <Tip>
      Because validation rules often include complicated logic and many rules, it's recommended to create validation rules through the dashboard to avoid any misconfiguration.
    </Tip>
  </Accordion>
</AccordionGroup>
