Skip to main content
POST
Simulate a rule
Dry-runs a rule against sample data. Nothing persists: no balances move, no counters increment, no events are recorded. This endpoint evaluates one rule. It does not execute other rules or rule sets in the program, so it cannot prove cross-set ordering or set-local stop_after_match behavior. See Testing multiple rule sets for the full-program test boundary. The event field is required and should mirror a real event payload. As with real ingestion, numeric values whose magnitude exceeds 2^53 are rejected with 400 amount_precision_exceeded; send very large values as strings. Participant context comes from one of two mutually exclusive sources (supplying both returns a 400):
  • participant_id: loads a real participant’s current state and ledger balances, so participant.balance.<symbol> conditions evaluate against actual values. Returns 404 if the participant doesn’t exist. Still a dry run: nothing is locked or written.
  • participant_state: caller-supplied mock state (tags, counters, attributes, optionally tiers and balances). Counter values may be JSON numbers or decimal strings; both are evaluated numerically.
With neither, the condition evaluates against empty defaults (counters 0, no tags, attributes, tiers, or balances), and the response carries a missing_participant_context warning if the condition reads participant state. Balance comparisons never match without balances. The response pairs the rule’s metadata (rule) with the simulation outcome (evaluation): matched, status (evaluated, or condition_failed with a reason), and per-action results when matched. Result fields vary by action type; state projections (current_value, would_add, and similar) are included only when the action targets the event participant. VOID_HOLD actions are not yet supported in simulation. SCHEDULE_EVENT and BROADCAST are not executed, but their payload templates are resolved, so a bad template surfaces here before the rule ever fires on a live event. Amount constraints match production: an asset action whose amount resolves to zero, negative, or beyond the precision-safe range fails in its result (COUNTER deltas may still be negative). To check CEL syntax without an existing rule, use the validate endpoint; to dry-run an unsaved rule, use simulate a draft rule.
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

diagnostics
boolean

Diagnostics opts into clause values, missing paths, short-circuit decisions, active-window and reachability outcomes. The normal response remains compact.

Example:

true

event
object

Event is the sample event data to evaluate against the rule. Kept as raw JSON so numeric values can be precision-checked before the float64 decode (numbers above ±2^53 are rejected — SCR-323). Supply exactly one of event or event_id.

Example:
event_id
string<uuid>

EventID selects a stored event for historical diagnostics. Its original payload/timestamp are used, and the execution-linked rule_history snapshot is preferred over the current rule when available.

Example:

"550e8400-e29b-41d4-a716-446655440004"

event_timestamp
string<date-time>

EventTimestamp optionally supplies the occurrence time for a sample event. Diagnostics report the active-window outcome against this timestamp. It is rejected for event_id, which always uses the stored event timestamp.

Example:

"2026-07-21T12:00:00Z"

participant_id
string<uuid>

ParticipantID optionally identifies a real participant whose current state (tags, counters, attributes, tiers — the same fields production rule evaluation sees) is loaded as the simulation's participant context. Mutually exclusive with participant_state. The simulation remains a dry run: no state is read with locks and nothing is written.

Example:

"550e8400-e29b-41d4-a716-446655440000"

participant_state
object

ParticipantState is optional simulated participant state (tags, counters, attributes). Conditions read it via the dot-access shorthand (participant.counter/tag/attribute., with safe defaults) or the get(participant.counters, ...) form, matching production evaluation. Counter values may be JSON numbers or decimal strings (the wire format returned by the participant state endpoints); both are evaluated numerically. Mutually exclusive with participant_id.

Example:

Response

Simulation result

evaluation
object

Evaluation contains the simulation results

rule
object

Rule contains metadata about the rule that was simulated

warnings
object[]

Non-blocking advisories about the simulation context — e.g. missing_participant_context when the rule's condition reads participant state but the request supplied neither participant_id nor participant_state, so the condition evaluated against empty defaults.