Inline checks in the inbox.
Offer your users "is this mail real?" right in the inbox - as an API call shaped like the Safe Browsing you already use. JSON in, verdict out.
A trust feature that keeps your users.
Differentiation from the big providers - with EU hosting as a selling point.
One pipeline, one call
scan_email takes headers and body, returns verdict, confidence and signals.
Built for throughput
A reputation cache and heuristics before the model keep cost and latency low.
EU hosting as a feature
Frankfurt/Falkenstein, no model training, named subprocessors - sellable.
From first request to inbox button.
Stable contracts, OpenAPI spec, predictable quotas.
Build against the spec
OpenAPI 3.1 at /docs/api. Bearer token with scopes, clear error codes.
Embed in the mail client
A "check" button per mail; the verdict shows as a banner in the inbox.
Scale
Higher quotas and an SLA via the Business tier as usage grows.
"Our users want to know if a mail is a scam. We don't want to train our own model."- PM, German mail provider
Frequently asked questions
How do I integrate scam scoring into my mail flow?
Through the REST API: you send the message, get back a verdict with a confidence score and signal reasoning, and wire it into your inbound routing.
How fast is the scoring API?
Typically under 5 seconds to a verdict; on low confidence the system automatically escalates to a larger model.
Where is the mail content processed?
On EU servers, under EU Standard Contractual Clauses and with no use for model training - data handling your users can trust.