Loyalty Engine Processing
Headless. API-first. Event-native.
ReactorCX is an enterprise loyalty platform built as headless, real-time loyalty infrastructure. It evaluates program rules against every member activity as it happens, updates member state, records an auditable execution log and publishes events to the systems that render the member experience. Client-owned channels, CRM, CDP and messaging systems remain the experience layer; ReactorCX owns decisioning, value accounting and execution.
What ReactorCX is and is not
| ReactorCX is | ReactorCX is not |
|---|---|
| The system of record for member state: balances, tiers, segments, benefits, wallets | A CMS or front-end experience layer |
| A real-time rules and arbitration engine for earn, burn, promotions and eligibility | A customer data platform |
| A financial ledger for loyalty value with full lineage | A marketing execution or campaign delivery tool |
| An event publisher and integration hub: API, events, batch | A monolithic suite that replaces surrounding systems |
How the pieces fit
Channels talk to ReactorCX through APIs and batch feeds; ReactorCX decides, records and publishes; enterprise systems consume events and data.
Map this to your architecture with a platform architect.
Book an architecture reviewEverything that happens to a member is an Activity
Real-time first: every Activity is evaluated on arrival, Member State updates immediately, and events publish as the activity completes.
| Component | Responsibility |
|---|---|
| Activity | The single representation of anything that happens to a member: a purchase, a redemption, a check-in, a survey response, a reversal, a tier qualification or any custom event. Purchase and non-purchase behaviors share one evaluation path. |
| REST API | The synchronous entry point for enrollment, balance and status queries, eligibility checks, reward issuance and redemption, and member servicing. The same surface powers the ReactorCX consoles. |
| Rules engine | Evaluates every Activity against rules defined on four eligibility dimensions (who, where, when, what), applies financial guardrails, arbitrates overlapping offers and executes actions. |
| Member State | The unified, real-time representation of a member: balances and sub-balances, tiers, segments, preferences, status and custom attributes. |
| RCX Data | Persistent store for profiles, activity history, rule configurations and versions, accrual lineage and operational state. |
| Events and Event Handlers | Replication events (Level 1, create/update/delete) keep external systems in sync; business events (Level 2) fire on loyalty actions such as earning, tier changes and reward issuance. Handlers subscribe only to what they need, under the same access framework as the API. |
| Scheduler | Time-based processing: effective-dated rule activation, scheduled launches, expiry warnings and accrual expiry, publishing events such as ExpirationWarningEvent, AccrualExpiryEvent and TierExpirationWarningEvent. |
| Execution log | For every Activity: which rules triggered, which actions executed, the input payload and the result. Answers what happened, why, which rule fired and what data was used. |
Concept page: Activity processing model.
Three integration modes, one behavior
API
Synchronous decisions: earn at the point of sale, eligibility, balance, redemption, servicing. Selective retrieval returns only the fields you ask for and protects integrations from model changes. Embedded lookups resolve references server-side in one call. Extension awareness exposes custom fields immediately.
Events
Downstream systems react or stay in sync in near real time. Delivered through the Event API, webhooks, Apache Kafka, Pulsar, or cloud streaming from AWS, Azure and GCP, so events flow through the observability, security and routing layers the enterprise already runs.
Batch (FeedXChange™)
Partner and coalition data exchange on file schedules: co-branded cards, airlines, hotels and other partners. FeedXChange™ handles configuration, connectivity, security, execution and monitoring of hundreds or thousands of feeds. Each row is processed as an individual real-time transaction, so batch behavior matches synchronous behavior.
Environments in sync, versioned configuration
Lower environments are kept in sync with production, so validation reflects what production actually runs. Program teams build and validate in stage, export the version as JSON, and publish into production when ready. Publish and unpublish control when rules are active, every change is captured in the audit trail, and folders with attribute-based access govern who can change which rules.
This is the control layer that makes speed safe: reviewable, reversible and auditable before a change touches production members. AI-prepared changes pass through the same gates; see AI and MCP.
Build in stage
Configure and validate against replayed traffic.
Version
Export the program version as JSON.
Review
Approve the change; access scoped by folder and rule.
Publish
Import to production without a restart.
Audit and rollback
Every change logged; unpublish reverts.
Named integrations
ReactorCX is in production with named enterprise booking and property management systems, including Opera PMS at MGM Resorts in real time, and Intopia for booking and reservations. The integration team works with the client's existing system administrators rather than requiring booking-vendor engagement.
Geo-aware personalization runs inside the API: the client passes coordinates and ReactorCX returns only the offers relevant to nearby locations, with no SDK required.
Harmonized integration
Rather than handing over an API and expecting client teams to wire everything alone, the implementation team maps the full enterprise architecture and ensures every system participating in the loyalty flow connects correctly, recommending changes to adjacent systems where needed. The team's integration experience pre-dates the ReactorCX platform itself. See Implementation and Ownership.
Frequently asked questions
Is ReactorCX a headless loyalty platform?
Yes. ReactorCX evaluates eligibility and program logic, issues outcomes, publishes events and exports data, while client-owned digital and marketing systems render the member experience. It is not a CMS, not a CDP and not a marketing execution tool.
What does API-first mean in ReactorCX?
Every ReactorCX console is built on the same REST APIs exposed to client systems. Anything achievable in a ReactorCX UI is achievable through the API, with selective retrieval, embedded lookups and extension awareness.
Which event streaming technologies does ReactorCX support?
Apache Kafka, Pulsar and cloud streaming services from AWS, Azure and GCP, plus the Event API and webhooks. Events are published at two levels: replication events for state synchronization and business events for loyalty actions.
What environments does ReactorCX provide?
A production environment and the lower environments each customer needs, such as development, test and QA, performance and load, or training. Lower environments are kept in sync with production, and configuration moves between them with JSON import and export.
How are custom data extensions exposed?
When the core data model is extended with custom fields and entities, those extensions become available in the API immediately, with no separate release.
Validate the architecture yourself, then talk to the people who built it.
The documentation is public. An Architecture Review maps ReactorCX to your systems, integration modes and environment model.