POST /api/v1/verify
Versioned REST, organization-scoped Bearer credentials, bounded request rates and the same canonical decision vocabulary used inside Clean.
Bearer authJSON600 rpm / keyPersisted receipts
Open developer console →One verification contract from UI to API.
Put Clean at the edge of signup flows, CRM imports and internal tools with organization-scoped credentials and evidence-backed responses.
RESTBearer authJSONVersioned v1
REQUESTcurl
curl -X POST https://clean.leadstrium.com/api/v1/verify \
-H "Authorization: Bearer cln_live_••••" \
-H "Content-Type: application/json" \
-d '{"email":"person@company.com","policy":"standard"}'
HTTPS · JSONOrganization-scoped credential
RESPONSE MODEL
Build against meaning, not a mystery score.
The public contract is designed around a small decision vocabulary plus the evidence and receipt context needed to explain that decision.
decisionconfidencerecommended_actionevidencereceipt
decision"review"
confidence"medium"
recommended_action"review"
evidence{ syntax · dns · risk }
receiptimmutable reference
Evidence supports sending under the selected policy.
Evidence is usable but warrants human or policy review.
Evidence supports keeping the address out of the send path.
Clean refuses to fabricate certainty when evidence is incomplete.
INTEGRATION PRINCIPLES
Predictable where it matters.
Tenant-bound credentials
API keys are organization-scoped and stored by hash rather than as retrievable plaintext secrets.
Stable version boundary
The verification endpoint lives under /api/v1 so clients integrate against an explicit contract.
Bounded traffic
Each API key is governed by a request-rate boundary instead of unbounded application pressure.
Same decision authority
The API does not implement a cheaper or separate validator. It resolves through the same Clean engine.
Build on the same trust engine your operators can inspect.
Use one API contract for point-of-capture decisions while keeping the resulting evidence visible to humans inside Clean.