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
  }
}
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. For credit/debit actions, the result includes the resolved amount, the asset_symbol, and a human-readable description. For counter actions, it includes current_value, projected_value, and value. For TAG actions, it includes current_tags and would_add. For UNTAG actions, it includes current_tags and would_remove. For attribute actions, it includes current_value and would_change. 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