Sortance routes each email across the email verification and enrichment providers you are already comparing, caches hard, and returns one decision with its reasons, its receipts, and a calibrated bounce probability underneath.
# Active policy, compiled once from two sentences:
# Don't allow temp emails or role accounts.
# Review companies outside fintech or insurance, or under 50 people.
curl -X POST https://api.sortance.com/v1/decide \
-H "Authorization: Bearer $SORTANCE_KEY" \
-d '{"email":"mia@acme.com","context":{"purpose":"signup"}}'Verification and enrichment are what the router buys; each card names the providers behind it, and says so where a contract is not yet confirmed. The decision is what it returns.
POST /v1/verifyWill mail to this bounce, and who is behind it?
POST /v1/enrichWho is this person, and what company are they from?
Using your own upstream key is not available yet. Enrichment pricing is not yet published; the pricing below covers verification.
POST /v1/decideGiven all that and your rules, does this one get in?
A model turns your sentences into typed rules once, when you write them, and asks instead of guessing when a sentence is ambiguous. From then on every request is decided by plain code: the first matching rule wins, and no model sits on the request path. Before you enforce a policy, Sortance replays it over your recent decisions. Then you enforce it, or run it in shadow first.
Don’t allow temp emails or role accounts. Anyone on our partners list is always allowed. Let AI agents in through the API-key flow. Review companies outside fintech or insurance, or under 50 employees.
Static example. This page calls no model; on your account the compiler runs on your text, once, when you click.
r_partnersallow{
"field": "email.domain",
"op": "in_list",
"list": "partners"
}If the domain is on your ‘partners’ list, allow. Checked first, so it overrides everything below.
r_no_disposabledeny{
"field": "verification.email_type",
"op": "eq",
"value": "disposable"
}Deny when the address is on a disposable-email domain.
r_no_roledeny{
"field": "verification.email_type",
"op": "eq",
"value": "role"
}Deny role accounts like info@ or sales@.
r_agentsallow_with_flow → api-key{
"field": "verification.actor_class",
"op": "eq",
"value": "agent_mailbox"
}Send AI agent mailboxes to the ‘api-key’ flow instead of the normal signup.
r_industry_fitreview{ "any": [
{
"field": "enrichment.company.industry",
"op": "not_in",
"value": ["fintech", "insurance"]
},
{
"field": "enrichment.company.employees",
"op": "lt",
"value": 50
}
] }Review, don’t deny, when the company is outside fintech or insurance or under 50 employees. When company data is missing the rule is skipped, so a gap in enrichment never turns into a lost signup.
default_actionallowNothing matched, or every rule that could have was missing its data: the request is let in.
Send Gmail, Outlook.com and other personal mailboxes to review instead of letting them straight in. AI agents go to the API-key flow.
Static example. This page calls no model; on your account the compiler runs on your text, once, when you click.
r_agentsallow_with_flow → api-key{
"field": "verification.actor_class",
"op": "eq",
"value": "agent_mailbox"
}Send AI agent mailboxes to the ‘api-key’ flow. Checked first, so an agent on a free provider still gets its flow.
r_free_reviewreview{
"field": "verification.email_type",
"op": "eq",
"value": "free"
}Review free (social) email: Gmail, Outlook.com, Yahoo, Apple and the like. Review, not deny: nothing is turned away without a person looking.
default_actionallowNothing matched, or every rule that could have was missing its data: the request is let in.
One POST, one payload. The decision says which of your rules fired and why; the verification inside it is the same object the other three tabs show, never reshaped.
The decision is your policy's, never Sortance's. rule_id names the rule that matched (null when the default action applied), policy names the exact version, and reasons states each fact that fired. If every upstream fails, decision is still set: the policy's default, with a degraded reason.
Bought only because a rule reads company.industry and company.employees, and only after the earlier rules had passed. Company first, by domain, so no person lookup. coverage says how much of what was asked for came back; sources is the receipt for each upstream that was called.
Providers hand back valid / invalid / unknown. That is a label, not a probability. We calibrate against observed bounces, so 0.31 means roughly 31 in 100 — and the interval tells you how much to trust that number before you decide.
How far apart the pool landed on the same address. Zero means they agreed and one cheap check would have done. High means the address is genuinely ambiguous — a fact no single verifier can report, because it only sees itself.
Human mailbox, agent mailbox, relay alias, or role account. Deliverability and who is on the other end are different questions, and SMTP only ever answers the first one.
One call at the signup form, one answer, and the receipts for every upstream it took to reach it.
Providers return a label. Sortance returns a distribution, the spread behind it, and what kind of mailbox produced it.
Rules that cost nothing, Sortance’s own second-opinion check, then a model that reads the domain the way a person would. A paypa1.com signup passes the first two: it has mail servers and is on no list. Only the third sees a domain dressed up as PayPal. On our test set, the third layer flagged 0 of 674 real domains.
free · every requestCan this domain receive mail at all?
free · first in the poolA second opinion on what the gate let through.
/v1/screen · after MX resolvesDoes the name itself look wrong?
Once the domain’s MX resolves, screening asks the next question: did this person type their own address, and is the name they gave a real one? It catches gmial.com, a jhon.smtih@ typed by someone who called themselves John Smith, and placeholders like test@, names like Mickey Mouse or asdf asdf, and domains like paypa1.com. One call, POST /v1/screen. It answers allow or review, never a block.
Illustrative example, not customer data
curl -X POST https://api.sortance.com/v1/screen \
-H "Authorization: Bearer $SORTANCE_KEY" \
-d '{"email":"jhon.smtih@gmail.com","name":"John Smith"}'The suggestion is a corrected address you can offer back on the form. The response never carries a score or a probability, only the labels.
| Reason | From | Review? |
|---|---|---|
syntax_invalid | Gate | review |
address_blocklisted | Gate | review |
domain_blocklisted | Gate | review |
domain_no_mx | Gate | review |
disposable_domain | Gate | review |
domain_allowlisted | Gate | noted |
address_allowlisted | Gate | noted |
domain_typo | Code check | review |
local_part_typo_of_name | Code check | review |
placeholder_address | Code check | review |
name_mismatch | Code check | noted |
domain_suspicious | Model | review |
fake_name_likely | Model | review |
name_email_inconsistent | Model | noted |
The gate and the code checks are free and always run, including when the domain has no MX, which is exactly when a typo suggestion matters. The model is asked only after the MX resolves: about the name only when you sent one, and about the domain in a separate request that carries the domain name alone, never the address or the name. Big consumer providers like gmail.com skip it.
Metered on its own allowance, 10,000 screenings a month by default, separate from verifications. A mismatch between a name and an address is noted, not penalised: plenty of real people use an address unrelated to their name. How screening works.
Per-check pricing went from about $25 per 10K in 2019 to $0.00045–$0.01 today. Anyone can buy a verdict on an address.
A deliverable mailbox can belong to an AI agent, a relay alias or a shared inbox. Valid is no longer evidence that a person, let alone a customer, is on the other end.
That answer depends on your rules, not ours. Sortance applies the policy you wrote and tells you which rule decided.
Run a policy change as an experiment, in shadow or enforced, and score it on events you report or Stripe reports. Sortance’s own decision counts are never the metric: denying more is not an outcome.
Illustrative example figures, not customer data
Beta posteriors, not p-values. Below the minimum sample the report shows no probability at all, and each address always lands in the same variant.
| Segment | Signups | Paid | Rate (90% interval) |
|---|---|---|---|
mailbox_type: consumer | 1,204 | 19 | 1.7% 1.1%–2.3% |
mailbox_type: corporate | 1,424 | 131 | 9.3% 8.0%–10.5% |
corporate + company.industry: fintech | 212 | 41 | 19.6% 15.3%–24.2% |
actor_class: agent_mailbox | 38 | 0 | 2.5% 0.1%–7.4% |
Joins are exact when your Stripe customer carries metadata.sortance_trace_id; otherwise they fall back to the email address, which is approximate, and every report counts joins by method (here 2,210 exact, 418 by email, 97 unmatched).
Segments under 30 signups are listed as too few to say. A segment that clearly underperforms becomes a suggested rule, proposed as review, never deny, and offered as an experiment first.
Same protocol, same providers, two very different outcomes depending on who hosts the mailbox.
The gap isn’t a provider being bad at its job. Microsoft-hosted domains largely stopped answering SMTP probes truthfully, and a catch-all domain accepts every address by design — no verifier can resolve it, ours included.
That’s where fan-out pays: on the addresses one provider can’t settle, the spread between four of them is itself information. On Google Workspace mail, a single cheap check is usually enough, and Sortance will tell you so instead of billing you four times for it.
Figures: Microsoft 365 51.4% valid · Google Workspace 90.6% valid.
Deliberate: per-check pricing pays us to check more, which is the opposite of what you want. Per send protected pays us to check less — cache harder, gate more locally, fan out only where it changes the answer.
For reference, raw per-check pricing across the pool runs $0.00045–$0.01 per check. We buy at that; you pay for the decision, however many checks it took.
Get an API keyThree things Sortance deliberately does not do.
Fit is a rubric you write: weighted criteria, added up by plain code, with the share of criteria that could actually be checked printed beside the number. A model helps you write rules once, when you write them. It never runs on a request.
A deny only ever comes from a rule you confirmed. Our suggestions propose review, the default action is allow, and every response names the rule and policy version that decided it.
No pixel, no private graph, no data we collected ourselves. Every enrichment fact is bought from a named upstream and shows up in that request's receipt, attributed to it.