POST /v1/decide

What happens, in order

1. Verify. The same pipeline as /v1/verify, your Blocklists included. Its answer is embedded unchanged as verification.
2. Load configuration. The active policy for the slug, any running experiment, the lists the policy names, and the ICP rubric.
3. Decide whether to enrich. Rules are walked in order. If an earlier rule settles the request — a disposable address denied by rule one — no profile is bought, and a policy that reads only verification signals costs the same as a bare verify.
4. Enrich, only for the fields the rules read, under what is left of the cost ceiling.
5. Score ICP, when the account has a rubric.
6. Evaluate. First matching rule wins; no match means the policy’s default action. Shadow variants are evaluated alongside and recorded on the decision, but do not change the answer.

No model runs anywhere on this path. A model helps you write a policy, once, when you compile it; every decision is a pure function of typed inputs, which is what makes it replayable.

Request

curl -X POST https://api.sortance.com/v1/decide \
  -H "Authorization: Bearer $SORTANCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "mia@acme.com",
    "context": {
      "purpose": "signup",
      "enrich": "auto",
      "max_cost_usd": 0.5,
      "attributes": { "plan_selected": "pro", "utm_source": "producthunt" }
    }
  }'

Malformed optional fields are ignored rather than rejected: on the signup path a typo in context must not become a failed signup. Only a missing or invalid address is a 400.

Response

Example shape. The values are illustrative, not measured.

{
  "decision": "review",
  "flow": null,
  "rule_id": "r_industry_fit",
  "tags": [],
  "policy": { "slug": "default", "version": 14 },
  "reasons": [
    "company.industry is 'logistics', not one of 'fintech', 'insurance'"
  ],
  "verification": { /* VerifyResponse, verbatim */ },
  "enrichment": { /* EnrichmentProfile, or null */ },
  "icp": null,
  "lists": { "matched": [] },
  "cost_usd": 0.1012,
  "latency_ms": 688,
  "trace_id": "dc_01J..."
}

It never fails closed

An enrichment outage, a missing policy or an unreadable list does not break your signup. The response is still 200, the decision is still set, and a degraded: line in reasons says what was missing. A predicate over missing data is unknown, an unknown rule is skipped unless it says on_unknown: "match", and no match means the default action — which is allow unless you chose otherwise.

Who can say deny

Only you. Sortance classifies — actor_class, email_type, mailbox_type, signals, enrichment, ICP fit — and a deny comes only from a rule in a policy you confirmed. That includes the Email types switches on the Policy screen: “free email: Block” is the rule r_type_free in your default policy, and the response names it (email types). The response names the rule and the version. The compiler prefers review over deny for rules that depend on enrichment, recommendations propose review, and the default action is allow.

Errors

The same envelope as every other endpoint: { "error": { "code", "message", "trace_id" } }. Decide never returns enrichment_quota_exceeded; enrichment trouble degrades the answer instead.