Your own
decision rules
Turn known signals into an ordered decision policy, then test it on stored events.
Decision trace
ExampleRules
- Input signalsA verify has email_domain_new. Your first enabled matching rule says limit.
- Reason ids
email_domain_newrule - Decision
limitreplaces the default decision; the verdict and score stay as they were. - GrantThe final decision selects the grant. Observe mode still allows.
How it works
Choose conditions
Match verdict, score, reasons, country, ASN, email domain, action, browser or verified agent.
Order the rules
Every condition must match. The first enabled matching rule wins.
Test on history
Replay seven or 30 days before saving. Read backtest limits.
API
Save rules through the authenticated dashboard API. The verify excerpt assumes a configured 100-credit trial.
// Dashboard session required
PATCH /api/sites/YOUR_SITE_KEY
Content-Type: application/json
{ "rules": [{
"id": "new-domain",
"name": "Limit new domains",
"enabled": true,
"when": [{ "field": "reason", "op": "has",
"value": "email_domain_new" }],
"then": "limit"
}] }
// Example subsequent verify response fields
{
"decision": "limit",
"grant": { "share": 0.2, "credits": 20,
"requires": null }
}Limits
- At most 20 rules per site, 10 conditions per rule and 50 entries per value list. Rule names are limited to 60 characters.
- Rules run only after a valid real-token verification. They cannot revive invalid, expired or replayed tokens, and public test keys do not run customer rules.
- Agent conditions match verified agent names only; a user-agent claim never matches. Missing signals do not match in; they do satisfy not_in.
- A matching rule adds a weightless rule reason. It does not change score, verdict, repeat counts or categories.
- Test on history scans at most the newest 50,000 verify events in the selected seven- or 30-day range. It makes no writes; missing historical fields are reported.
- Observe mode returns allow and the rule result in wouldDecide. Move to enforcement only when the proposed outcomes fit.