Skip to main content
POST
/
v1
/
rules
/
{id}
/
simulate
Simulate a rule
curl --request POST \
  --url https://api.scrip.dev/v1/rules/{id}/simulate \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: <api-key>' \
  --data '
{
  "event": {
    "amount": 75,
    "type": "purchase"
  },
  "participant_state": {
    "attributes": {
      "region": "US"
    },
    "counters": {
      "purchase_count": 9
    },
    "tags": [
      "vip"
    ]
  }
}
'
{
  "evaluation": {
    "matched": true,
    "reason": "<string>",
    "results": [
      {
        "action": {
          "amount": "event.amount * 10",
          "asset_id": "550e8400-e29b-41d4-a716-446655440002",
          "type": "CREDIT"
        },
        "result": {
          "amount": "750",
          "asset_symbol": "POINTS",
          "description": "Credit 750 POINTS to participant"
        }
      }
    ],
    "status": "evaluated"
  },
  "rule": {
    "condition": "event.type == 'purchase' && event.amount > 0",
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "name": "Purchase Reward",
    "order": 100,
    "stop_after_match": false
  }
}

Documentation Index

Fetch the complete documentation index at: https://docs.scrip.dev/llms.txt

Use this file to discover all available pages before exploring further.

Dry-runs a rule against sample data without persisting any changes. No balances are modified, no counters are incremented, and no events are recorded. The event field is required and should mirror the shape of a real event your system would send. The participant_state field is optional and lets you provide mock tags, counters, and attributes so the condition can reference participant data. The response contains two top-level objects:
  • rule: static metadata about the rule: id, name, condition, order, and stop_after_match
  • evaluation: the simulation outcome:
    • matched: whether the condition evaluated to true
    • status: evaluated on success, or condition_failed if the CEL expression errored
    • reason: error message, present only when status is condition_failed
    • results: present only when matched is true. Each entry pairs the original action definition with a result containing computed values
Action results vary by type:
Action typeResult fields
CREDIT, DEBIT, HOLD, RELEASE, FORFEITamount, asset_symbol, description
COUNTERcurrent_value, projected_value, value, description
TAGcurrent_tags, would_add, description
UNTAGcurrent_tags, would_remove, description
SET_ATTRIBUTEcurrent_value, would_change, description
SET_TIERdescription
SCHEDULE_EVENTdescription
BROADCASTdescription
VOID_HOLD actions are not yet supported in simulation. For asset actions, amount reflects the resolved CEL expression (if dynamic) and asset_symbol is the symbol of the target asset. Participant-state projections (current_value, would_add, etc.) are only included when the action targets the event participant. Use this to validate rule logic before deploying, or to debug why a rule isn’t matching in production. To check CEL syntax without needing an existing rule, use the validate endpoint.
For usage patterns and examples, see the Writing Rules guide.

Authorizations

​
X-API-Key
string
header
required

API key passed in the X-API-Key header.

Path Parameters

​
id
string<uuid>
required

Rule ID

Body

application/json

Sample event and optional participant state

​
event
object
required

Event is the sample event data to evaluate against the rule

Example:
{ "amount": 75, "type": "purchase" }
​
participant_state
object

ParticipantState is optional simulated participant state (tags, counters, attributes)

Example:
{
  "attributes": { "region": "US" },
  "counters": { "purchase_count": 9 },
  "tags": ["vip"]
}

Response

Simulation result

​
evaluation
object

Evaluation contains the simulation results

​
rule
object

Rule contains metadata about the rule that was simulated