Decision policy

Soryxa Rules and Review Queue

Configure Soryxa rules to return allow, block, or review decisions, then use the review queue for addresses that should not be handled automatically.

Get API Key View Reason Codes

Policy control loop

1 Draft a rule policy with allow lists, block lists, thresholds, and messages.
2 Backtest supported list, toggle, and threshold changes, then publish in enforce, shadow, or staged rollout mode.
3 Route review outcomes to a queue owner instead of hiding them as allow or block.

Documentation map

Pick the product or implementation step before you wire authentication, responses, limits, or events.

Suite docs

Docs home Company Domain Lookup Elvesora Enrichment

Soryxa API

Overview Validate email Reason codes API errors Usage and credits Batch validation Rules and review queue Webhooks and connectors

Decision model

Soryxa response examples should be read from the decision field first. Do not build new workflows around older boolean-only validation assumptions.

allow

The address can continue through the configured workflow.

block

The address should stop before it enters the next customer workflow step.

review

Signals are mixed, risky, temporary, or configured to require a manual decision path.

Rules configuration

Rules should be explicit enough for automation and conservative enough to protect legitimate users from being silently stopped by uncertain signals.

Default policy: scores below 70 go to review. A score cannot block by itself until the team sets block_threshold_score above zero. Allow lists, block lists, disposable rules, bogus domains, and invalid classifications are evaluated separately.

Rule area	Behavior
Allow list	Allow known-safe addresses or domains before broader blocking rules apply.
Block list	Block addresses or domains that should never pass the workflow.
Disposable domains	Choose whether disposable patterns are blocked or sent to review.
Free providers	Decide whether consumer mail providers are allowed, blocked, or routed to review.
Role accounts	Control addresses such as info@, support@, billing@, and other shared inboxes.
Policy keys	Use policy_key to apply a named rule policy such as signup or CRM intake.
Score thresholds	The default review threshold is 70. Score-only blocking is disabled by default and starts only when block_threshold_score is set above zero.
Score weights	Adjust how individual validation signals affect the final score.
Customer messages	Configure customer-facing messages for allow, block, and review decisions.
Rollouts	Publish changes in enforce, shadow, or staged modes before applying them broadly.
Backtests	Compare allow and block lists, disposable, free-provider, and role-account block toggles, and review and block score thresholds against recent validation logs. Score weights, customer messages, policy keys, and rollout settings are not included in the current backtest payload.

Draft and publish

Rule changes are saved as drafts before publishing. Published revisions are immutable so a team can inspect history and roll back to a known policy.

Rollout modes

Shadow and staged rollouts let a team measure policy impact before enforcing a rule change for every validation.

Review privacy

Plaintext review records support manual decisions. Hashed display modes can automatically approve or block review outcomes when plaintext review is not used.

Decision response

Save the decision and reason code together so later workflow decisions can be explained.

{
  "success": true,
  "data": {
    "decision": "review",
    "reason_code": "SCORE_BELOW_THRESHOLD",
    "decision_message": "Email needs review.",
    "decision_reasons": [
      "Validation score is below the review threshold."
    ],
    "score": 58
  }
}

Reason code examples

SCORE_BELOW_THRESHOLD review

Score was below the configured review threshold.

SCORE_BELOW_BLOCK_THRESHOLD block

Score was below a score-only block threshold explicitly enabled by the team.

DISPOSABLE_REVIEW review

Disposable signal exists but policy sends it to review instead of block.

BLOCK_DISPOSABLE block

Disposable signal matched a blocking rule.

ALLOW_LIST_MATCH allow

Address or domain matched a configured allow list.

REVIEW_HISTORY_APPROVED allow

A prior manual review approved the same address for this team.

REVIEW_HISTORY_REJECTED block

A prior manual review rejected the same address for this team.

Review queue behavior

The review queue is for validation outcomes that need judgment before another workflow proceeds. It should not be used as a hidden allow or block state.

1 Open the review queue for records with a review decision.
2 Inspect policy_key, reason_code, decision_reasons, checks, score, and the upstream signal summary.
3 Choose the final downstream action for the address, such as allow the signup, block the workflow, or request another address.
4 Record the outcome next to the original validation result so later exports and connector deliveries stay explainable.
5 Use hashed auto-resolution only for teams that intentionally hide plaintext addresses from the review queue.