Your first request

Every check is one call to POST /email/check with a JSON body containing the address you want evaluated. Through RapidAPI, authentication is already handled for you - just call the endpoint from RapidAPI's console or your own code using your RapidAPI key, no separate token needed.

{
  "email": "user@example.com",
  "mode": "standard",
  "context": "signup"
}

mode and context are both optional - they default to "standard" and "generic" if you leave them out. See the other tutorials in this listing for what each one changes.

Reading the response

The response is intentionally rich - every check returns the full picture, not just a single number:

Field	What it tells you
`decision`	The routing decision: `allow`, `review`, or `block` - most integrations only need to branch on this
`risk`	A 0-100 score, a level, a confidence value, and a per-category breakdown of what contributed
`signals`	Every specific fact that fed the score, each with a severity and a point impact - this is what makes the score explainable rather than a black box
`verification` / `deliverability`	Separate reads on "is this address syntactically/structurally valid" vs. "is the mailbox actually reachable"
`checks`	The raw pass/fail facts (syntax, MX, disposable, free provider, role-based, catch-all, typo) each signal is derived from
`domain`	Domain-level intelligence: reputation, mail infrastructure, registration age, SPF/DMARC presence

Here's a full example response for user@example.com:

{
  "email": "user@example.com",
  "decision": "allow",
  "risk": { "score": 5, "level": "low", "confidence": 0.7, "breakdown": { "email_quality": 0, "domain": 0, "disposable": 0, "provider": 0, "deliverability": 5, "reputation": 0 } },
  "verification": { "status": "unknown", "domain": "verified", "mailbox": "unknown", "confidence": 0.73 },
  "deliverability": { "status": "likely_deliverable", "confidence": 0.65 },
  "email_quality": { "score": 100, "classification": "normal" },
  "signals": [
    { "code": "SMTP_UNKNOWN", "severity": "low", "impact": 5, "description": "Mailbox existence could not be confirmed - SMTP verification is not yet performed." }
  ],
  "checks": {
    "syntax_valid": true, "domain_exists": true, "mx_found": true, "smtp_check": "unknown",
    "disposable": false, "free_provider": false, "role_based": false, "catch_all": false, "typo_detected": false
  },
  "domain": {
    "domain": "example.com", "type": "business", "has_mx": true, "spf": true, "dmarc": true,
    "reputation": { "score": 85, "classification": "trusted", "confidence": 0.75 },
    "domain_age": { "days": 11329, "classification": "established" }
  },
  "meta": { "processing_ms": 32, "cached": false, "mode": "standard", "context": "signup", "request_id": "req_00a471c1-3757-4237-9305-e2bd90f595da" }
}

A good default rule: allow lets the signup/lead/transaction through, review flags it for manual attention or a softer friction step, and block stops it outright. Where exactly you draw those lines is your call - the risk.score and signals array give you everything needed to build your own policy instead of trusting a single opaque threshold.