Headless. API-first. Event-native. Batch taken seriously.
ReactorCX, the enterprise loyalty platform from Loyalty Methods, connects through REST APIs its own consoles use, event streams to Kafka, Kinesis, Event Hubs, Pulsar or webhooks, and FeedXChange™ batch feeds. It acts on every signal according to your program's configuration, answers the channel in the moment, keeps connected systems current and takes back what they learn, so each interaction informs the next.
Integration
Three modes, one model
REST
Selective retrievalsame APIs as the consolesEvents
Level 1 and Level 2replication · named business eventsBatch
FeedXChange™ filessplit to transactionsHarmonized
One data modelwhichever mode arrivesEvery interaction recorded against the member activity that caused it
Every interaction makes the next one sharper
Your channels and partners send signals. ReactorCX acts on each one according to your program's configuration and answers while the member is still there: which offers, promotions and rewards they see, what they earn and what they can redeem. It records the outcome, keeps every connected system current and takes back what those systems learn, so each member's next interaction is more relevant than the last.
Three integration modes
The right mode depends on the downstream system: some need synchronous responses, others need event feeds, others need periodic files.
REST APIs the platform itself uses
Every user interface in ReactorCX is built on the same REST APIs exposed to client systems. Anything achievable in a ReactorCX console is achievable through the API.
Event streams, including your own events
Level 1 replication events keep external systems in sync. Level 2 business events fire on the loyalty actions that need a downstream response, and your program can define custom events of its own.
FeedXChange™
Configuration, connectivity, security, execution and monitoring for hundreds or thousands of partner feeds. Each row runs as a real-time transaction.
Partner ecosystemAPI traits that protect your integrations
- Selective retrieval. Client systems select just the elements they need from each call, reducing response size and processing cost, and protecting existing integrations from data model changes.
- Embedded lookups. Resolve references and sub-objects and perform server-side lookups inside a single call rather than chaining round trips.
- Extension awareness. When teams extend the core data models with custom fields and entities, those extensions are available in the API immediately. Configure it today, query it today.
- Geo-aware. REST calls accept latitude and longitude and perform radial geo search to filter offers by proximity, with configurable radius and no SDK required.
Event levels and named business events
| Level | Purpose | Event types |
|---|---|---|
| Level 1 · replication (CUD) | Keep external systems in sync near-real-time without polling | ObjectInsertEvent, ObjectUpdateEvent, ObjectDeleteEvent |
| Level 2 · business events | Respond 1:1 to specific loyalty conditions: milestones, triggered email, partner notifications | AddPointsEvent, RedeemPointsEvent, SetTierEvent, EnrollmentEvent, AddRewardEvent, UseRewardEvent, RewardReversalEvent, AddBadgeEvent, ExpirationWarningEvent, TierExpirationWarningEvent, GenerateReferralEvent, CompleteReferralEvent, AccrualExpiryEvent, AccrualEscrowEvent |
| Custom events · defined by your program | Publish events on conditions your program defines, alongside the events ReactorCX provides | Named and shaped by your team |
Downstream systems subscribe to the events they need. Inbound, custom activities sent by channels and partners run through the same rules engine. Subscription scope is controlled by the same access framework that governs API access.
How events reach your systems
Activity processed
Rules evaluated, member state updated, execution log written
Events emitted
Level 1 replication and Level 2 business events
Event Flow Designer
Enrich payloads with additional useful information
Streaming targets
Kafka · Pulsar · AWS Kinesis · Azure Event Hubs · GCP · webhooks · APIs
Enterprise systems
CRM, CDP, ESP, warehouse and analytics act on events and send what they learn back
Complex event processing
Pattern detection runs through the same real-time rules engine as single-event transactions, supporting multi-event promotions, streak and challenge progression and qualification logic that spans channels and time windows.
Streaming ingestion
An Event API publishes loyalty and engagement events as they occur; a streaming ingestion endpoint accepts inbound event streams, including custom activities and data returned by connected systems, for near-real-time processing.
Privacy and security
Two privacy modes: PII inside the platform with full data-subject-rights support, or tokenized identifiers with PII held in your systems. TLS in transit, AES-256 at rest, role- and attribute-based access, audit logs across all three modes.
Map your channels, partners and downstream systems with an architect.
Book an architecture reviewHarmonized integration
Rather than handing over an API and expecting client teams to wire everything up alone, the Loyalty Methods implementation team works from the full picture of the enterprise's architecture and makes sure every system participating in the loyalty flow connects properly, recommending optimizations to adjacent systems and, where appropriate, helping implement changes across the stack. That draws on more than a decade of enterprise loyalty integration experience that pre-dates the ReactorCX platform itself.
Named production integrations include Opera PMS at MGM Resorts, and Intopia for booking and reservations. At 7-Eleven, geo-filtered offers surface only the offers available at nearby stores.
Scale the integration model runs at
How this is measured
Distinct physical sites transacting through ReactorCX integrations, each counted once. As of 2026-Q3.
How this is measured
Real-time API requests per day served for the largest single ReactorCX deployment (retail); not platform-wide. As of 2026-Q3.
Platform-wide <200 ms API response SLA. Definitions and as-of dates →
Frequently asked questions
What is the ReactorCX integration model?
Three complementary integration modes, API, events and batch, built to connect a loyalty program to the customer-facing and back-end systems that surround it. Real-time channels use API and events; partner integrations typically use batch through FeedXChange™.
What event levels does ReactorCX expose?
Level 1 replication events (ObjectInsertEvent, ObjectUpdateEvent, ObjectDeleteEvent) keep external systems in sync near-real-time. Level 2 business events fire on specific loyalty actions such as point earning, tier changes, reward issuance and referral completion. Programs can also define custom events of their own.
Can we define our own events?
Yes, in both directions. Channels and partners can send custom activities, which ReactorCX processes through the same rules engine as any other interaction. Programs can also publish custom events on conditions they define, alongside the events ReactorCX provides.
How do connected systems improve what ReactorCX does next?
They send back what they learn. A CDP can return segments and scores, messaging tools can return responses, service tools can return outcomes and partners can return their own data, through the API, streaming ingestion or batch feeds. Returned member data informs the next decision straight away, and program teams use it to refine segments, offers and rules, which still go through review and approval.
Which event streaming technologies does ReactorCX support?
Cloud streaming offerings from Azure, AWS and GCP, and on-prem deployments of distributed brokers such as Apache Kafka and Pulsar, so events flow through the observability, security and routing layers the enterprise already operates.
Does ReactorCX support batch integration?
Yes. FeedXChange™ simplifies the configuration, connectivity, security, execution and monitoring of hundreds or thousands of feeds. Each row in a partner feed is split into an individual transaction and runs through the same real-time rules engine as API and event traffic, so batch behavior is consistent with synchronous behavior.
Related: Architecture and extensibility · Safe migration · Financial integrity · API reference · Event catalog
Read the documentation, then talk to the people who wrote it.
Concepts, API reference, event catalog and integration guides are public. Engineers are one form away.