Skip to main content
Short definitions for every term you will meet in the docs and the API. Each links to the guide that covers it in depth.

​
A

  • Account: A balance container in the ledger for one entity, asset, and bucket combination. Created automatically on first use. Ledger
  • Action: What a rule does when its condition matches: credit, debit, hold, tag, counter increment, and more. Rule Actions
  • Adjustment: A manual credit or debit you make directly through the API (the /balances/adjust endpoint), as opposed to a balance change made by a rule. Used for goodwill credits, corrections, and support operations. Recorded as a CREDIT or DEBIT journal entry with event_id and rule_id both null. There is no separate adjustment action type. Balance Operations
  • allow_negative: Debit option that lets a balance go below zero, used for refund clawbacks after funds were spent. Balance Operations
  • Archive: Retiring a resource. Archived resources are hidden from default listings, but the consequences differ by resource: an archived asset is permanently retired, an archived program can be reactivated, an archived tier is ended for good, and an archived rule is a soft delete. Each resource’s guide states its own rules. Data Model
  • Asset: The unit of value participants earn and spend: points, cashback dollars, credits. Defined at the organization level and linked to one or more programs. Asset Configuration
  • Attribute: A key-value string on a participant or group, readable in rule conditions. State Management
  • Automation: A stored event submission that Scrip fires on a trigger, delivering the stored event_data as an event to the program or to each matching participant. Automations

​
B

  • Brand: The merchant or organization associated with a product. One brand can have several orderable products. Reward sources
  • Breakage: Issued value that will never be redeemed, such as expired or forfeited balances. Recorded against the SYSTEM_BREAKAGE account. Reporting
  • Bucket: One of three pools inside every balance: AVAILABLE (spendable), HELD (reserved by holds), and DEFERRED (not yet matured). Ledger
  • Budget: A cap on how much of an asset a rule can issue, optionally resetting on a schedule. Its scope is PROGRAM (one pool shared across all participants, the default) or PARTICIPANT (a separate cap for each participant). Writing Rules

​
C

  • Campaign: A time-bound promotion built from rules with an active_from and active_to window, grouped so it can be launched, capped, and retired as a unit. Not a separate resource. Campaigns
  • CEL: Common Expression Language, the syntax for rule conditions and dynamic values. CEL Expressions
  • Claim link: A URL a participant opens to access a successfully fulfilled reward. Gift cards
  • Condition: The CEL expression that decides whether a rule’s actions fire for an event. Writing Rules
  • Counter: A named numeric value on a participant or group, incremented by rules or the API, readable in conditions. State Management

​
D

  • Dynamic value (${{ }}): The wrapper that marks an action field value as a CEL expression, as in "amount": "${{ event.amount * 0.1 }}". Unwrapped values are literals. Rule Actions

​
E

  • Enrollment: A participant’s per-program membership, separate from the participant’s own status. Created automatically when a participant’s first event reaches a program. Participants
  • Event: The input to Scrip: a record submitted to or generated by Scrip (a purchase from your application, an automation firing) that triggers rule evaluation. Event Processing
  • Event trace: The rule_evaluations array on an event, recording which rules ran, matched, or were skipped when the event was processed. Event Processing
  • Execution status: The execution_status field on a participants-scoped automation, tracking the current fan-out run (idle, executing, completed, failed) independently of the automation’s own status. Automations
  • external_id: Your application’s identifier for a participant. Scrip resolves it to its own id. Participants

​
F

  • Face value: The amount a participant can spend with a gift card. The API expresses it in currency minor units, such as cents for USD. Gift cards
  • Fan-out: The delivery of one automation firing as an individual event to every matching participant. Automations
  • Forfeit: Permanently removing balance from a participant or group, moving it to breakage. Balance Operations
  • Fulfillment: The process of delivering a redeemed reward. Your application can resolve custom rewards; Scrip resolves gift-card orders against a connected fulfillment account. Redemption lifecycle
  • Fulfillment account: The account you connect and fund to pay for gift-card orders. Manage it in the Scrip dashboard. Gift cards

​
G

  • Gift card: A reward participants can spend with a merchant. Scrip orders the card when a participant redeems. Gift cards
  • Group: A shared ledger entity for multiple participants: families, teams, organizational pools. Groups
  • Guard condition: An automation’s optional CEL expression checked per participant at fire time; returning false skips that participant’s event. Automations

​
H

  • Hold / Release / Settle: Ways to set value aside in HELD and finish it later. A hold moves a participant’s own funds from AVAILABLE to HELD, and a release moves them back. For a card authorization, a rule usually credits pending rewards straight into HELD with the authorization’s reference_id. A settle is a later CREDIT with the same reference_id and no bucket. It replaces those pending rewards with the settled amount. Funds moved with a hold are finished with a release, not a settle. Balance Operations

​
I

  • Idempotency key: A caller-supplied key that makes retries safe. For events it is the event’s identity; for balance operations and redemptions, replays return the original result. API conventions
  • Inventory mode: The immutable asset setting choosing SIMPLE (one aggregate balance) or LOT (each credit tracked individually). Asset Configuration
  • Issuance policy: The immutable asset setting choosing UNLIMITED (credits mint new value) or PREFUNDED (credits draw from a funded program wallet). Asset Configuration
  • Issuer attribution: Knowing which program’s wallet funded a credit, tracked per lot for cross-program settlement. Lots & Expiration

​
J

  • Journal entry: One immutable ledger record of a balance change, with balancing debit and credit postings. Ledger

​
L

  • Ledger: The double-entry record of every balance change. Nothing is mutated in place. Ledger
  • Ledger entity: Anything that can hold balances: a participant, a group, a program wallet, or a system account. Ledger
  • Liability: The value you owe participants: outstanding balances not yet redeemed, expired, or forfeited. Reporting
  • Lifecycle event: A webhook event that announces a resource changing state, such as redemption.completed or participant.created. It carries the resource id and its status, never a journal entry id. Webhooks
  • Lot: An individually tracked credit with its own remaining amount, issuer, and optional expiration or maturity dates. Debits consume the oldest eligible lots first. Lots & Expiration

​
M

  • Managed reward: A catalog reward that Scrip creates and maintains from a reward source, such as a gift card. Rewards catalog
  • Maturity: A future date before which a credited lot sits in the DEFERRED bucket. Used for vesting. Lots & Expiration
  • Movement event: A webhook event that announces one journal entry: balance.*, transfer.completed, and program.*. Every journal action has exactly one, and together they record every participant and group balance change. Webhooks

​
O

  • Order: A rule’s or rule set’s current position in its execution sequence, always numbered 1, 2, 3 and so on with no gaps. Scrip manages the numbering; you place things with position and the move/reorder endpoints. Rule Sets
  • Organization: The top-level tenant. Programs, assets, participants, and API keys all belong to one organization. Authentication

​
P

  • Participant: A user in your system, identified by your external_id. Exists at the organization level and can enroll in multiple programs. Participants
  • Position: The semantic placement (first, last, before, after) used to place a rule or rule set when creating or moving it. Rule Sets
  • Posting: One side (debit or credit) of a journal entry, against one account and bucket. Ledger
  • Posting time: A journal entry’s created_at, the moment the ledger recorded it. Statement and transaction history from and to select rows by posting time, not by the event’s event_timestamp. Reporting
  • Product: An item available from a fulfillment account, with its own supported countries, currencies, and card values. Include it through a reward source to add it to your catalog. Reward sources
  • Program: The top-level container for rule sets, rules, linked assets, and enrolled participants. Usually one per use case. Programs
  • Program wallet: The funded balance a PREFUNDED asset’s credits draw from. Empty wallet means credits fail. Programs

​
R

  • Redemption: Spending balance, either against a reward catalog item or as a raw amount. Redemptions
  • Reservation: A durable authorization that claims an exact amount of a participant’s HELD balance for a pending redemption. Redemption lifecycle
  • Reversal: Clawing back what a completed event’s rules credited, capped at the original awards, with unrecoverable value reported as shortfall. Redemptions have their own reversal endpoint with the same capped, partial-friendly semantics. Reversing an Event
  • Reward: A catalog item participants can redeem balance for. Rewards Catalog
  • Reward source: The configuration that adds products from a fulfillment account to a program’s catalog and sets their asset prices. Reward sources
  • Rollforward: A report that explains how a balance changed over a period: the opening balance, named amounts for everything that moved it, and the closing balance. The amounts always add up to the difference. The liability rollforward covers the organization by asset and program. The participant rollforward covers one participant by asset. Liability rollforward, Participant rollforward
  • Rule: A CEL condition paired with a list of actions, evaluated when events arrive. Writing Rules
  • Rule configuration: A program’s complete rule state: its rule sets, rules, positions, statuses, actions, and budgets, treated as one unit for changes, history, and rollback. Managing Rule Configuration
  • Rule configuration simulation: A dry run of a program’s complete rule configuration against many sample or historical events. It simulates the live configuration, or a draft you send as rule_configuration, and shows each event’s rule trace and balance changes. It leaves live rules, balances, budgets, and participant state unchanged. The results remain available to review. Testing
  • Rule configuration version: A counter on the program that goes up by one on every change to its rule configuration. Scrip stores the full configuration at each version, so you can list past versions, see what changed (the history endpoints call these records “revisions”), and roll back. Passing the current version with a write rejects the request if someone else changed the configuration first. Managing Rule Configuration
  • Rule set: A named, ordered container for rules. Sets run in order, rules run in order inside each set, and stop_after_match stops only its own set. Rule Sets

​
S

  • Scale: The immutable number of decimal places for an asset’s amounts. Asset Configuration
  • Statement: A running-balance view of one participant, group, or program wallet for one asset: each posting in posting order with the balance after it, plus opening and closing balances for the window. Covers all buckets, or only the buckets you select with bucket. Reporting
  • stop_after_match: A flag on a rule that skips the remaining rules in that rule’s set after a successful match. Other sets continue. Writing Rules covers the field. Rule Sets covers how the stop interacts with set order.
  • Subscription: The per-participant schedule record a participant-state automation maintains, carrying that participant’s next_trigger_at. Automations
  • System accounts: The ledger’s world-side accounts: SYSTEM_ISSUANCE (source of minted value), SYSTEM_REDEMPTION (destination of redeemed value), and SYSTEM_BREAKAGE (destination of expired or forfeited value). Ledger

​
T

  • Tag: A boolean label on a participant or group, such as vip, readable in conditions. State Management
  • Target: The participant, group, or program an action applies to. Defaults to the event’s participant. A dynamic target is looked up with an expression, such as a referrer ID saved on the participant. Rule Actions
  • Tier: A ranked level in a progression track, assigned to participants directly, by rules, or by automatic qualification. Tiers
  • Transfer: An atomic movement of value between two participants or groups. Transfers
  • Trigger: The condition that determines when an automation fires: a recurring cron schedule, a one-time moment, or participant state. Automations

​
V

  • Void-hold: Cancelling pending rewards that were credited straight into HELD, used to reverse all or part of a card authorization. Balance Operations

​
W

  • Webhook: A signed HTTP delivery Scrip sends to your endpoint when something happens: an event completes, a balance changes, a participant is created. Webhooks