Inline-Prüfung im Postfach.
Biete deinen Nutzern „Ist diese Mail echt?" direkt im Postfach - als API-Aufruf in der Form, in der du Safe Browsing schon nutzt. JSON rein, Urteil raus.
Ein Vertrauens-Feature, das deine Nutzer hält.
Differenzierung gegenüber den großen Anbietern - mit EU-Hosting als Verkaufsargument.
Eine Pipeline, ein Aufruf
scan_email nimmt Header und Body, gibt Urteil, Konfidenz und Signale zurück.
Gebaut für Durchsatz
Reputation-Cache und Heuristiken vor dem Modell halten Kosten und Latenz niedrig.
EU-Hosting als Feature
Frankfurt/Falkenstein, kein Modelltraining, namentliche Subprozessoren - verkaufbar.
Von der ersten Anfrage zum Inbox-Button.
Stabile Verträge, OpenAPI-Spec, vorhersagbare Quoten.
Gegen die Spec bauen
OpenAPI 3.1 unter /docs/api. Bearer-Token mit Scopes, klare Fehlercodes.
In den Mail-Client einbetten
Ein „Prüfen"-Button pro Mail; das Urteil erscheint als Banner im Postfach.
Skalieren
Höhere Quoten und SLA über den Business-Tier, sobald die Nutzung wächst.
„Unsere Nutzerinnen wollen wissen, ob eine Mail Betrug ist. Wir wollen kein eigenes Modell trainieren."- PM, deutscher Mail-Provider
Häufige Fragen
Wie integriere ich Scam-Scoring in meinen Mail-Fluss?
Über die REST-API: Du schickst die Nachricht, bekommst ein Urteil mit Confidence-Score und Signal-Begründung zurück und baust es in dein Inbound-Routing ein.
Wie schnell ist die Scoring-API?
In der Regel unter 5 Sekunden bis zum Urteil; bei geringer Sicherheit eskaliert das System automatisch an ein größeres Modell.
Wo werden die Mail-Inhalte verarbeitet?
Auf EU-Servern, unter EU-Standardvertragsklauseln und ohne Nutzung für KI-Training - Datenhaltung, der deine Nutzer vertrauen können.