Skip to main content
A program is the top-level container in Scrip. It holds your rule sets and rules, links to your assets, and scopes your participants. You might have one program for your entire rewards system or separate programs for distinct business lines, such as customer rewards and employee recognition. Programs provide isolation. Rules in one program never trigger on events sent to another program.

​
Creating a program

A program only requires a name. You can set the enrollment policy and other options at creation or update them later.
The response returns a program_id that you’ll use when sending events, creating rule sets and rules, and querying balances. Scrip also creates a default rule set for the program. Rules that omit rule_set_id are assigned to it. See Rule sets when you need separate tracking, earning, or maintenance groups inside one program.

​
Redemption fulfillment

fulfillment_mode and pending_redemption_ttl set the program default for redemptions that omit capture. See Redemption lifecycle for instant vs asynchronous capture, deadlines, and PENDING resolution.

​
The program wallet

Every program has a wallet. How it’s used depends on the asset’s issuance policy:
  • UNLIMITED credits mint new value directly. The wallet is bypassed. This is what most programs use.
  • PREFUNDED credits draw from the wallet. You fund it up front, and every credit to a participant debits the wallet. When the wallet is empty, credits fail. This is how you enforce a fixed budget.
If you’re using PREFUNDED assets, you manage the wallet with fund and burn:

​
Linking assets

Assets exist at the organization level. To use an asset in a program, it must be linked. When you create a new asset with a program_id, the link happens automatically. To share an existing asset across programs, link it manually:
This is how you create a shared economy, where participants earn the same asset across multiple programs.
An asset cannot be unlinked from a program if any ledger entries exist for that asset in that program.

​
Program state

Programs support the same state types as participants: tags, counters, and attributes. Use them for global logic that isn’t tied to any one participant. For example, a “first 1,000 signups” cap using a program-level counter:
Signups from different participants at the same moment cannot pay more than 1,000 bonuses. When the COUNTER finds that another signup already took the count to 1,000, the condition is false against that value, so the rule is skipped with reason SHARED_STATE_CHANGED and its CREDIT rolls back. See Shared program and group state. See State Management for more on program-level state.

​
Program status

You can pause or retire a program by updating its status:
Archived programs can be reactivated by setting status to ACTIVE or SUSPENDED. To change behavioral settings such as on_unknown_participant or redemption targets, reactivate the program first.

​
Enrollment

Existing participants are automatically enrolled in a program the first time an event targets them in that program. This applies across all identity paths and requires no configuration. Inactive enrollments are reactivated. Enrollment status is per-program and separate from the participant’s own status; see Participants: Auto-enrollment of existing participants. The on_unknown_participant setting controls what happens when an event arrives for a participant that doesn’t exist yet: Most programs use CREATE for simplicity. Use REJECT when you need strict control over who can participate.

​
Automations

Programs can have automations that generate events on a schedule, at a specific time, or in response to participant state changes. Automations are scoped to a program and managed via POST /v1/programs/{id}/automations. See Automations for details.