Programs
A program is the container for your reward logic. It holds your rule sets and rules, links to your assets, and enrolls your participants. Most teams create one program per use case: “Customer Rewards,” “Referral Rewards,” or “Driver Incentives.” Events are always sent to a specific program. Rule sets belong to one program, and every rule belongs to one set in that program.Assets
An asset is the unit of value you’re tracking. Points, cashback dollars, nights stayed, referral credits. Assets live at the organization level and can be linked to more than one program, so the same points can be earned across campaigns. You configure how each asset behaves:- Inventory mode:
SIMPLEtracks a single aggregate balance.LOTtracks each credit individually with its own expiration, maturity, issuer lineage, and oldest-first spending. - Issuance policy:
UNLIMITEDmints new value on every credit (no cap).PREFUNDEDdraws from a fixed program wallet, so credits fail when the wallet is empty. UsePREFUNDEDwhen you need to enforce a budget.
Participants
Participants are your users. You identify them with your ownexternal_id so they stay in sync with your application. Like assets, participants exist at the organization level and can enroll in multiple programs. They can be created explicitly or automatically on first event.
Each participant carries state that rules can read and write:
- Tags: Boolean flags like
viporfirst_purchase. - Counters: Numeric values like
lifetime_spendorpurchase_count. - Attributes: Key-value strings like
region: "US".
Events
Events are the inputs. Your application sends one whenever something happens that might affect a participant: a purchase, a signup, a referral, a cancellation.idempotency_key ensures exactly-once event processing: if you retry with the same key, you get back the same event identity instead of processing it again. To correct or replace an event, send a new event with a new idempotency key.
Rule sets and rules
A rule set groups related rules and provides their execution priority. Every program has an automaticdefault set, so you can create a rule without passing rule_set_id.
A rule is a condition and a list of actions. The condition is a CEL expression (Common Expression Language, a lightweight expression syntax) evaluated against the event and the participant’s event-start state. When it returns true, the actions fire.
ACTIVE rule by rule-set order, then by its position inside the set. Multiple rules can fire on the same event. For mutually exclusive logic, place the rules in one set and use stop_after_match: true to skip the remaining rules in that set. Other sets continue.
Together, a program’s rule sets, rules, positions, and statuses form its rule configuration, which Scrip versions as one unit so you can change, audit, and roll it back safely. See Managing rule configuration.
The Ledger
Every balance change is recorded as a journal entry with two sides: a debit and a credit. When a participant earns points, the credit goes to the participant and the corresponding debit comes from a source account: the system issuance account forUNLIMITED assets, or the program wallet for PREFUNDED. Nothing is ever mutated in place.
This gives you a complete audit trail: you can trace any balance back to the event and rule that created it.
Every balance is split into three buckets. available is what the participant can spend right now. held is reserved by hold operations, such as a card authorization waiting to settle. deferred is credited value that has not matured yet, used for vesting. Most programs only ever see available; the other two exist when you use holds or maturity dates.
End-to-End Example
Using the “Cashback on large purchases” rule from above, here’s what happens when a $105 purchase comes in:1
Your app sends an event
user_123 made a $105 purchase. You send it to Scrip with external_id: "user_123" and event_data: {type: "purchase", amount: 105.00}.2
The engine loads the participant
Scrip looks up the participant matching
user_123 and loads their current state: tags, counters, and attributes.3
The rule set and rule evaluate
The program’s sets and their active rules run in set and rule order. The condition
event.type == 'purchase' && event.amount >= 100.0 is checked. 105 >= 100, so it matches.4
The CREDIT action fires
$10 is credited to the participant’s balance.
5
The ledger records it
A journal entry credits
user_123 by $10 and debits the source account by $10 (the system issuance account for an UNLIMITED asset, or the program wallet for PREFUNDED).6
Result
user_123 now has $10.00 available to redeem.