CheckSignup Integration & API Guide
Integrate real-time email verification into your SaaS backends, auth flows, and AI Coding Agent environments.
Detailed OpenAPI 3.1 specifications for /validate and /health endpoints.
Interactive real-time playground to test disposable detection and canonical aliases.
Open Live Sandbox →Connect Claude Code, Cursor, and Windsurf to email intelligence tools via MCP.
Configure MCP Server →Generate secure API keys (cs_live_...) and monitor real-time credit consumption.
🔑 Authentication & Request Headers
All API calls to https://api.checksignup.com/validate are authenticated and metered using your secret API key. We support both HTTP Bearer headers and custom API key headers:
| Header | Format / Type | Requirement | Description |
|---|---|---|---|
Authorization | Bearer cs_live_... | Recommended | Standard RFC 6750 Bearer authentication token. |
X-API-Key | cs_live_... | Optional | Legacy custom header alternative to Authorization Bearer. |
Idempotency-Key | UUID / String | Optional (Best Practice) | 24-hour operation binding. Prevents double-charging credits on network retries. |
Content-Type | application/json | Required for POST | Standard JSON payload declaration. |
⚡ Code Integration Samples
Choose your preferred language to see working code with 3-State policy directives and idempotent retry support:
curl -X POST https://api.checksignup.com/validate \
-H "Authorization: Bearer cs_live_your_api_key_here" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d" \
-d '{"email": "test.user+promo@gmail.com"}'📦 Production JSON Response Schema
Every validation returns an authoritative edge verdict containing canonical normalization, DNS MX routability, classification flags, integer risk score (0–100), and a 3-State action directive:
{
"email": "test.user+promo@gmail.com",
"normalized": "testuser@gmail.com",
"domain": {
"name": "gmail.com",
"created_at": null,
"age_days": null
},
"mx": [
{
"exchange": "gmail-smtp-in.l.google.com",
"preference": 5
}
],
"valid": {
"syntax": true,
"mx": true
},
"flags": {
"disposable": false,
"free": true,
"forwarding": false,
"role": false
},
"typo_suggestion": null,
"risk_score": 10,
"action": "allow",
"reason": "free_email_provider",
"degraded": false
}Response Attribute Descriptions:
| Field | Type | Meaning & Edge Logic |
|---|---|---|
normalized | string | Deterministic canonical address (e.g. dots/plus tags removed for Gmail/Proton/Outlook). Use as your primary unique key. |
flags.disposable | boolean | True if the apex or subdomain matches our trie of hundreds of thousands of disposable domains or 250+ rotating MX clusters. |
flags.free | boolean | True for major consumer webmail providers (Gmail, Yahoo, Outlook, Proton, iCloud, AOL, Zoho). |
flags.forwarding | boolean | True for email privacy relay masks (SimpleLogin, AnonAddy, Firefox Relay, DuckDuckGo). |
flags.role | boolean | True for generic department addresses (admin@, support@, billing@, sales@, info@). |
typo_suggestion | string | null | Levenshtein-distance typo correction (e.g. user@gmial.com → user@gmail.com). |
risk_score | integer (0–100) | Deterministic weighted score. 0 represents verified B2B corporate mail; 90+ represents burner relays or dead MX. |
action | 'allow' | 'review' | 'block' | High-level 3-State policy recommendation for automated gating in signup pipelines. |
degraded | boolean | True if upstream DNS exceeded 150ms timeout and safe fallback rules were triggered without blocking real users. |
🛡️ 3-State Policy Directives Guide
Rather than forcing your developers to write brittle regex trees, CheckSignup computes an authoritative 3-state directive designed for zero-friction signups:
Clean Signups & Prototyping
Legitimate corporate domains and clean consumer mailboxes. Provide immediate dashboard access without additional verification barriers.
Suspicious or Masked Aliases
Forwarding relays, role-based mailboxes, or subtle domain typos. Prompt the user with typo confirmation or require an email OTP before granting trial credits.
Burners & Delivery Failures
Known disposable mailboxes, broken syntax, or unroutable DNS MX records. Reject the signup request immediately with a generic error message.
🚨 HTTP Status Codes & Errors
CheckSignup follows standard RFC HTTP status codes. All errors return a structured JSON payload with error and message fields:
| Status Code | Error Code | Description & Actionable Remedy |
|---|---|---|
| 200 OK | - | Validation succeeded. Inspect action and risk_score in the payload. |
| 400 Bad Request | missing_email / invalid_syntax | The request body did not supply an email address or contained malformed characters. |
| 401 Unauthorized | missing_key / invalid_key | API key is missing or invalid. Verify your key in the developer console. |
| 402 Payment Required | insufficient_credits / quota_exceeded | Monthly quota depleted. Top up credits in your console to resume operations. |
| 429 Too Many Requests | rate_limit_exceeded | Tier RPS exceeded. Inspect the Retry-After header and throttle retry pace. |
| 503 Unavailable | service_unavailable | Upstream settlement or edge routing degraded. Retry with exponential backoff. |
🔒 Zero-Plaintext PII Storage Guarantee (INV-6)
GDPR CompliantCheckSignup operates under strict zero-plaintext PII boundaries. Email strings are evaluated ephemerally in Cloudflare Edge RAM and never written to permanent disk storage or plain-text database logs. Audit logs only preserve one-way SHA-256(email) digests and domain metadata.