From add4c75afb4c35ab39293b526e5a9cbe0222c4c5 Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Mon, 22 Jun 2026 07:10:48 +0000 Subject: [PATCH] docs: clarify qualifications sorting vs stacking and loyalty Total points --- documentation/analyze/campaign-tracking.mdx | 2 +- documentation/guides/checking-eligibility.mdx | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/documentation/analyze/campaign-tracking.mdx b/documentation/analyze/campaign-tracking.mdx index 82253c148..ce6e4ea3a 100644 --- a/documentation/analyze/campaign-tracking.mdx +++ b/documentation/analyze/campaign-tracking.mdx @@ -72,7 +72,7 @@ The campaign dashboard shows: - **Publications, messages delivered, redemptions by distributions**: Distribution performance. - **Campaign point expiration**: Point expiration rules. - **Total validations, redemptions, rollbacks, publications** chart. -- **Total points**: Aggregated points earned, redeemed, expired, and more. +- **Total points**: Aggregated point totals for the campaign, including points earned, redeemed, expired, subtracted, and pending. These figures sum activity across all loyalty cards in the campaign and match the [loyalty point balance types](/build/loyalty-points#loyalty-point-balance-types) tracked on individual cards. - **Total vouchers created/deleted** chart. - **Access settings**: Lists assigned areas and stores (enterprise feature available on demand). diff --git a/documentation/guides/checking-eligibility.mdx b/documentation/guides/checking-eligibility.mdx index 196c5db78..24f57478b 100644 --- a/documentation/guides/checking-eligibility.mdx +++ b/documentation/guides/checking-eligibility.mdx @@ -46,6 +46,16 @@ To specify the types of promotions and codes that you want to reveal to your cus In the request, you can add [options](/api-reference/qualifications/check-eligibility) to configure the parameters returned in the response, e.g. filters for types of redeemables or sorting rules like `BEST_DEAL` or `LEAST_DEAL`. + + The `options.sorting_rule` parameter only controls the **order in which qualified redeemables are listed in the qualifications response**. It does not change the order in which incentives are applied at redemption. + + - `DEFAULT` – sorts descending by `created_at`. + - `BEST_DEAL` – sorts descending by `total_applied_discount_amount` (the redeemable with the highest discount appears first). + - `LEAST_DEAL` – sorts ascending by `total_applied_discount_amount`. + + The actual application order during validation and redemption is always governed by your project's [stacking rules](/orchestrate/stacking-rules) (for example, **Category hierarchy** or **Requested order**) and by the order of redeemables you pass in the redemption request. Sorting the qualifications response with `BEST_DEAL` does not override stacking configuration. + + ## Use cases The following scenarios show a couple of use cases that are possible with the qualifications API. Depending on the scenario, you send a slightly different API call and the results are returned in the context of the scenario.