Skip to main content
Set up a purchase reward program: create a program and asset, add a rule, send an event, and watch a user’s balance increase automatically. About 15 minutes.

​
1. Set up your environment

Grab your API key from the Scrip dashboard and set it as an environment variable:

​
2. Create your Program & Asset

A Program is the container for your reward logic. An Asset is the unit of value you’re tracking (points, credits, etc.). Create the program first:
The id is your program_id; you’ll pass it in every subsequent call. Now create a points asset and link it to the program:
scale: 0 means whole numbers only (10 points, not 10.5). SIMPLE mode keeps one running balance per participant, which is all this quickstart needs; use LOT mode when credits need their own expiration or vesting dates (see Lots & Expiration). inventory_mode is immutable after creation. The id here is your asset_id for the next step.

​
3. Define a Rule

Rules tell Scrip when to give out points. This rule gives 10 points for every event where the type is "purchase":
The condition is a CEL expression. The amount here is the literal string "10"; to compute an amount from the event instead, wrap a CEL expression in ${{ }}, like "amount": "${{ event.amount * 0.1 }}" for 10% back. Plain values are literals, wrapped values are expressions. This request omits rule_set_id, so Scrip assigns the rule to the program’s automatic default rule set. You can add named sets later without changing this single-set flow. See Rule sets.

​
4. Send an Event

Send a purchase event for a user. The external_id is whatever ID you use for this user in your own system. You don’t need to create the participant first. Scrip creates and enrolls them automatically when their first event arrives.
The API returns 202 Accepted: the event is queued, and a worker processes it in the background, usually within a second or two. event_timestamp records when the event actually happened, which is what time-based rules evaluate against. The idempotency_key makes retries safe: resending the same key returns the same event instead of crediting twice.

​
5. Verify it processed

Fetch the event by the id from the previous response:
status: "COMPLETED" with a SUCCESS evaluation means the rule matched and its credit was applied. This rule_evaluations trace is your primary debugging tool:
  • Still PENDING? The worker hasn’t picked it up yet; wait a moment and refetch.
  • COMPLETED but rule_evaluations is empty? The condition didn’t match. Check the condition against the exact event_data you sent (a typo like "purchse" fails silently, because event fields are schemaless).
  • FAILED? The response includes an error_code telling you why, such as an inactive program.

​
6. Check the Balance

Look up the participant by your external_id to get their Scrip id:
Then fetch their balances with that id:
There are the 10 points, in the available bucket (held and deferred come into play with holds and vesting). The rule matched the purchase event, credited the participant, and recorded the transaction in the ledger.

​
Next Steps

Now that you’ve seen the core loop, dive deeper:
  • Writing Rules: Use CEL to build complex logic (e.g., “double points for VIPs”).
  • Rule Sets: Group rules and control execution order across tracking, earning, and maintenance logic.
  • State Management: Use counters and tags to track user progress over time.
  • Redemptions: Let users spend those points on rewards.
  • API conventions: Errors, pagination, and idempotency across every endpoint.