> For the complete documentation index, see [llms.txt](https://kbase.whitelabel-loyalty.com/product/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/rule-based-campaigns/reactors.md).
# Reactors
Detailed reference for configuring reactors within Rule Based campaigns — triggers, conditions, reactions, activation limits, status, and editing behaviour.
### Adding a reactor
From the Rule Based campaign detail screen, click **Add Reactor** to create a new reactor within the campaign.
### Configuration
Each reactor requires the following:
1. **Name & description** *(optional)***:** Provide a name and description for the reactor. Both are designed to be shown to users.
2. **Picture** *(optional)*: Upload an image to represent the reactor.
3. **Event trigger** — Select the event type that should trigger the reactor by clicking the cog icon in the Event Trigger block. This could be a purchase, referral, account creation, or any custom event type you’ve defined.
4. **Conditions** *(optional)* — Define criteria the event or user must meet for the reactor to fire. See [Conditions](/product/loyalty-engine/campaigns/conditions.md).
5. [**Activation limits**](#activation-limits) *(optional)* — Specify how many times the reactor can trigger, over what period, either per user or across all users in the program.
6. **Reactions** — Select the actions that should occur when the reactor is triggered — such as adjusting points, issuing a reward, or calling a webhook. See [Reactions](/product/loyalty-engine/campaigns/reactions.md).
***
#### Event & reactor flow
When an event is reported to the Loyalty Engine, the following sequence occurs:
1. The engine identifies all active reactors that are listening for the reported event type.
2. For each matching reactor, conditions are evaluated against the event payload and user data.
3. Activation limits are checked and updated.
4. If all conditions pass, the configured reactions are executed.
Basic diagram of a reactor configuration
***
#### Triggers
Each reactor listens for a single event type. When an event of that type is reported, the reactor evaluates its conditions and potentially fires its reactions.
Event types include both **intrinsic events** (built-in events like `REGISTERED_ACCOUNT`) and **custom events** (events you define).
See [**Event Types**](/product/loyalty-engine/events/event-types.md) for more information on creating and managing event types.
***
#### Activation limits
Activation limits control how many times a reactor can trigger before it stops — either across your entire tenant, or on a per-user basis. Each limit applies over a **time period** you choose.
Specifying a daily subject activation limit of 1. Used for once per day, per user rewards.
**Limit period**
When setting an activation limit, you specify the period the count resets against:
| Period | Resets |
| ------------ | -------------------------------------------- |
| **Lifetime** | Never — the limit applies once for all time. |
| **Daily** | Each calendar day (00:00:00–23:59:59). |
| **Weekly** | Each calendar week (Monday–Sunday). |
| **Monthly** | Each calendar month (1st to last day). |
| **Yearly** | Each calendar year (1 January–31 December). |
These are **calendar** periods — the count resets at fixed boundaries regardless of when the user first triggered the reactor. All periods are evaluated in **UTC**.
For example, a limit of “once per user, daily” lets each user trigger the reactor once between 00:00:00 and 23:59:59 UTC, and the allowance resets at midnight. A limit of “5 per user, monthly” resets on the 1st of each month.
**Tenant activation limit**
A **tenant activation limit** applies across your entire tenant: once the reactor has triggered its allotted number of times in the period, it stops running for all users until the period resets (or permanently, for a lifetime limit). When a tenant limit is in place, there is no limit on how many times individual users can trigger the reactor unless additional criteria are specified.
**Subject activation limit**
A **subject activation limit** applies per user: each user can trigger the reactor its allotted number of times in the period before it stops processing their events until the period resets. When a subject limit is in place, the tenant limit is unlimited, and the reactor runs indefinitely unless otherwise restricted.
{% hint style="info" %}
If you need both tenant and subject limits, set a tenant activation limit and use [audience conditions](/product/loyalty-engine/campaigns/conditions.md#audience-conditions) to control the per-user limit — for example, an audience where users are only eligible if they’ve reported an event fewer than X times.
{% endhint %}
{% hint style="warning" %}
When setting activation limits, consider whether allowing unlimited activations could leave the reactor open to abuse. Appropriate limits help manage a reactor’s lifecycle and ensure it only triggers under controlled conditions.
{% endhint %}
***
#### Reactor lifecycle
A reactor has no lifecycle of its own — it’s managed entirely through its **campaign**. Reactors don’t have their own status, start date, end date, pause, archive, or clone actions.
* A reactor’s **timing** comes from the campaign’s start and end dates.
* **Pausing** the campaign stops its reactors from processing events; reactivating resumes them.
* **Archiving** the campaign, or the campaign’s end date passing, stops its reactors.
* Status (Active, Paused, Ended, Archived) is shown against the **campaign**, not against individual reactors or missions.
* To duplicate a reactor’s setup, **clone the campaign** — individual reactors can’t be cloned on their own.
See [Managing Campaigns](/product/loyalty-engine/campaigns/managing-campaigns.md) for the full lifecycle.
***
#### Editing a reactor
A reactor's own configuration — its conditions, reaction, and reward — can be edited at any point in the campaign's life: Draft, Active, or Paused.
Editing is in place and non-destructive. It doesn't create a new version of the reactor or reset its participation history; the same reactor keeps its recorded participants.
What locks once the campaign is published is the campaign's structure. You can't add reactors, remove them, or reorder them on a live campaign — those changes can only be made in Draft. To change the reactor line-up on a live campaign, clone the campaign, amend the draft copy, and publish that. See [Managing Campaigns](/product/loyalty-engine/campaigns/managing-campaigns.md).
***
#### FAQs
**Can a reactor be triggered by multiple event types?**
A single reactor listens for one event type. To create logic that requires multiple events to occur, use [audiences](/product/loyalty-engine/audiences.md) to bridge them.
**How do I avoid abuse or misuse?**
Reactors without appropriate limits can be exploited — for example, a promo code reactor giving 500 points with no activation limit allows unlimited claims. Use [activation limits](#activation-limits), [conditions](/product/loyalty-engine/campaigns/conditions.md), and [points earning caps](/product/loyalty-engine/rewards-and-points/points/points-earn-spend-and-balance-caps.md) to mitigate this.
**Can I set both tenant and subject activation limits at once?**
Not directly. Set a tenant activation limit and use audience criteria to handle the per-user limit, as the Loyalty Engine doesn’t support both simultaneously.
**What happens if I don’t set any activation limits?**
The reactor runs indefinitely. That’s fine for some use cases (like baseline points earning) but can lead to misuse if not monitored.
**How do I duplicate or end a reactor?**
Both are campaign-level actions. To duplicate a reactor’s setup, clone its campaign. To end a reactor, archive or end its campaign or let the campaign’s end date pass. See [Managing Campaigns](/product/loyalty-engine/campaigns/managing-campaigns.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/rule-based-campaigns/reactors.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
