Testing

Testing happens at three levels: one rule, a full program configuration, and your webhook handler.

Choose an endpoint

What you want	Where to send it
Check CEL and draft actions	`POST /v1/rules/validate`
Simulate a draft or saved rule	`POST /v1/rules/simulate` or `POST /v1/rules/{id}/simulate`
Simulate a full rule configuration, live or draft	`POST /v1/programs/{programId}/rule-configuration/simulations`
Inspect a processed event	`GET /v1/events/{id}`
Replay a webhook delivery	`POST /v1/webhook-deliveries/{id}/resend`

Author a single rule

For one rule, iterate without touching live balances:

Validate the condition (and optionally draft actions) with POST /v1/rules/validate.
Simulate the draft with POST /v1/rules/simulate.
Save the rule, then simulate the saved rule with POST /v1/rules/{id}/simulate, passing participant_id to run against live participant state.

Writing rules: Validation and simulation covers request fields, warnings, and event.* field checks. A simulation result also shows the bucket each asset action would use, so you can check that a settlement with a future matures_at lands in DEFERRED.

Test a full configuration

A rule configuration simulation tests a program’s rules together against sample or past events. It checks rule-set order, stop_after_match within each set, interactions between rules, and tier qualification after each event. It leaves live rules, balances, budgets, and participant state unchanged. You can retrieve the results afterward. Send it to POST /v1/programs/{programId}/rule-configuration/simulations. Leave out rule_configuration to simulate your live configuration. To simulate a draft, add the same draft you send to analysis and preview as rule_configuration. Both return the same per-event detail. Use scenario mode for sample events, or replay mode for past events with their original timestamps. Both let you check which rules match, when budgets stop a payout, and which rules stop_after_match skips. Set options.compare_live to run your live configuration and a draft against the same inputs. Include the draft in rule_configuration. Use trace or full detail to see ordered condition and action outcomes. See Managing rule configuration for analysis, simulations, and the preview/apply path. See Rule sets for execution order and set-local stopping.

Scenario events

A scenario simulation sends sample events through your rules, in the order you list them. This example sends an authorization and then its settlement for one participant:

POST /v1/programs/{programId}/rule-configuration/simulations

{
  "mode": "scenario",
  "initial_state": {
    "participants": [{ "external_id": "cardholder-1" }]
  },
  "scenario": {
    "event_definitions": [
      {
        "count": 1,
        "external_id": "cardholder-1",
        "event_data_template": {
          "type": "auth",
          "amount": 50,
          "authorization_id": "auth_001"
        }
      },
      {
        "count": 1,
        "external_id": "cardholder-1",
        "event_data_template": {
          "type": "settlement",
          "settlement_amount": 42,
          "authorization_id": "auth_001",
          "statement_close_at": "2030-01-31T00:00:00Z"
        }
      }
    ]
  },
  "options": { "detail_level": "full" }
}

This request simulates your live configuration. To simulate a draft, add rule_configuration to the request, using the same body you send to preview. The program comes from the path, so the body has no program_id.

Event definition field	Required	Description
`event_data_template`	Yes	The event’s data. Its `type` sets `event.type`. For a random value, use `{"min": 10, "max": 100}` to pick a decimal in that range, or `{"values": [...]}` to pick one item from a list.
`count`	No	How many events to create from this definition. If you leave it out, it defaults to `0` and the definition creates no events.
`external_id`	No	Sends the events to this participant. It must appear in `initial_state.participants`.
`participant_id`	No	Sends the events to the participant with this ID. It must appear in `initial_state.participants`.

If you set neither external_id nor participant_id, each event goes to a random participant. scenario.participant_count sets how many participants the simulation has in total. Scrip adds sample participants when initial_state lists fewer. Scenario events have no timestamp of their own. Every event in a scenario simulation gets the same time, which Scrip picks for that simulation. It is not the current time. Repeating the same simulation gives the same time-based results. To test an active window or a condition on now, replay real events, which keep their timestamps. You can also simulate one rule with an event_timestamp. The request returns 202 with the simulation’s id. Fetch the result with GET /v1/programs/{programId}/rule-configuration/simulations/{simulationId}. Each item in result.events has a posting_diffs list with one row for every balance change the event made. "detail_level": "full" is the default and includes these rows. Say the simulated configuration has two rules. One runs the authorization CREDIT from Auth / settlement pattern on auth events. The other runs the settlement CREDIT from Delay when settled rewards can be spent on settlement events. On an UNLIMITED asset, the settlement’s rows show 42 moving into DEFERRED, the 50 pending leaving HELD, and the unused 8 going back to system issuance. Other fields are left out here:

{
  "posting_diffs": [
    { "account_type": "PARTICIPANT", "bucket": "DEFERRED", "amount": "42" },
    { "account_type": "PARTICIPANT", "bucket": "HELD", "amount": "-50" },
    { "account_type": "SYSTEM_ISSUANCE", "bucket": "AVAILABLE", "amount": "8" }
  ]
}

At "detail_level": "full", an event can also have a lot_diffs list. The list appears only when the event creates, consumes, or changes the status of a lot. A SIMPLE asset has no lots, so its actions add no rows. Each row shows one change to a lot. These fields show which action caused it and what the lot looked like afterward:

Field	Description
`action_index`	Position of the action that changed the lot in the rule’s `actions` list, starting at `0`. Rows follow the order the rules and actions ran.
`operation`	`created` for a new lot, `consumed` for value taken from a lot, or `transitioned` for a lot that moved to another status.
`reference_id`, `matures_at`, `expires_at`	The lot’s reference ID and the dates when it becomes spendable or expires, after that action. Each appears only when the lot has one.

A row shows the lot as its action left it, even when a later action in the same event changes the lot again.

Testing an automation

An automation sends its saved event_data unchanged. Check what the rules will do, then check that the automation delivers the event:

What the rules will do. Send the automation’s event_data as a scenario event in a rule configuration simulation. The simulation shows which rules match and how balances would change, without changing live balances or state.
A real end-to-end run. Create a one-time copy of the automation: same event_data, a one_time trigger with trigger_at omitted so it fires immediately, and a participant_filter pinned to a test participant (for example participant.external_id == "test_user_1"). The copy delivers one real event to that participant and moves to completed. Verify it like any processed event: fetch the event, read rule_evaluations, and check the balance.

Automations: testing an automation shows the request in full.

Verify a processed event

Every event records what happened, which makes the event itself your main debugging tool:

GET /v1/events/{id}

status shows the lifecycle: PENDING → PROCESSING → COMPLETED or FAILED. Failed events carry a machine-readable error_code.
rule_evaluations is the execution trace: which rules matched, credited, or were skipped, in the order they ran. An empty trace on a COMPLETED event means no condition matched.
GET /v1/events/{id}/impact shows the ledger effect: every balance change the event caused, with system accounts as counterparties.

Failed events with a fixed underlying cause can be replayed with the retry endpoint.

Test webhooks

Webhook handling is part of your integration:

Replay real deliveries with the resend endpoint instead of manufacturing traffic. It re-dispatches a past delivery through the normal path with a fresh signature.
Verify signatures against the documented scheme, not by skipping verification in test environments. See Webhooks: Verify a signature.
Watch endpoint health with delivery stats and the delivery listing to catch failures your handler swallows.

Events sent to a development program emit real webhooks to that program’s configured endpoints, so a dev program plus a dev endpoint gives you an end-to-end rehearsal of the production flow.

Writing rules

Validation and simulation payloads for a single rule.

Managing rule configuration

Preview and apply a multi-rule change.

Webhooks

Verify signatures and replay deliveries.

Getting Started

Foundations

Earning

Participant State

Ledger & Balances

Spending

Operations

Advanced

Reference

Choose an endpoint

Author a single rule

Test a full configuration

Scenario events

Testing an automation

Verify a processed event

Test webhooks

Writing rules

Managing rule configuration

Webhooks

​Choose an endpoint

​Author a single rule

​Test a full configuration

​Scenario events

​Testing an automation

​Verify a processed event

​Test webhooks

Writing rules

Managing rule configuration

Webhooks

Choose an endpoint

Author a single rule

Test a full configuration

Scenario events

Testing an automation

Verify a processed event

Test webhooks