免费
每月 $0。无需信用卡。
- 免费 KYC 套件(身份验证 + 被动活体检测 + 人脸匹配 + 设备与 IP 分析), 每月 500 次,永久有效
- 黑名单用户
- 重复检测
- 每次会话 200+ 欺诈信号
- Didit 网络中可重复使用的 KYC
- 案件管理平台
- 工作流构建器
- 公开文档、沙盒、SDK、MCP(模型上下文协议)服务器
- 社区支持


全球2,000多家组织信赖。

不止于语法
我们实时测试送达率,标记一次性邮箱和角色邮箱,并返回一个 风险评分,供您的工作流进行分支判断。每次检查 $0.03。
选择您需要的检查项, 身份、活体、人脸比对、制裁名单、地址、年龄、电话、邮箱、自定义问题。在控制台中将它们拖入工作流,或通过我们的 API 发布相同的工作流。根据条件进行分支,运行 A/B 测试,无需代码。
通过我们的 Web、iOS、Android、React Native 或 Flutter SDK 进行原生嵌入。重定向到托管页面。或者直接向您的用户发送链接, 通过电子邮件、短信、WhatsApp,任何地方。选择适合您技术栈的方式。
Didit 负责托管摄像头、灯光提示、移动端切换和辅助功能。当用户在流程中时,我们实时评估 200 多个欺诈信号,并根据权威数据源验证每个字段。两秒内即可获得结果。
实时签名 Webhook 可确保用户批准、拒绝或发送审核后,您的数据库立即同步。按需轮询 API。或者打开控制台检查每个会话、每个信号,并按您的方式管理案例。
$ curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"workflow_id": "wf_email_check",
"vendor_data": "user-42"
}'{ "session_url": "verify.didit.me/..." }$ curl -X POST https://verification.didit.me/v3/email/check/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"reference_id": "ref_8a2c",
"code": "482913"
}'{ "status": "Approved", "is_breached": true }# Didit Email Verification — integrate in 5 minutes
You are integrating Didit's Email Verification module into <my_stack>.
Follow these steps exactly. Every URL, header, and enum value below is
canonical — do not paraphrase or "improve" them. The module covers:
syntax validation, MX (Mail Exchange) lookup, SMTP (Simple Mail Transfer
Protocol) deliverability probe, disposable-provider detection,
free-provider detection, breach exposure lookup (HaveIBeenPwned-style),
catch-all + role-based anti-abuse signals, OTP (one-time password)
confirmation, and a configurable risk policy that can chain straight
into a Know Your Customer (KYC) (know your customer) workflow.
## 1. Provision an account
- Sign up: https://business.didit.me (no credit card required).
- Or provision programmatically: POST https://apx.didit.me/auth/v2/programmatic/register/
(returns an API key bound to the workspace + application).
## 2. Two integration paths — pick one
### Path A — Workflow Builder (hosted UI)
Best when you want Didit to host the OTP entry screen, localize the
email template, handle resend cool-downs, and chain Email Verification
into a wider KYC / KYB workflow.
1. Create a workflow that contains the EMAIL_VERIFICATION feature:
POST https://verification.didit.me/v3/workflows/
Authorization header: x-api-key: <your-api-key>
Body: workflow_label, features array with the single entry
{ feature: "EMAIL_VERIFICATION" } (UPPERCASE — strict enum)
Optional config: per-warning action overrides (Decline / Review /
Approve) for BREACHED_EMAIL_DETECTED, DISPOSABLE_EMAIL_DETECTED,
DUPLICATED_EMAIL, and EMAIL_IN_BLOCKLIST.
2. Create a verification session for an end user:
POST https://verification.didit.me/v3/session/
Body: workflow_id (from step 1), vendor_data (your own user id),
optional contact_details.email (pre-fills the OTP step).
Response: session_url — redirect the user to it.
3. Listen for webhook callbacks (see "Webhooks" below).
### Path B — Standalone server-to-server API
Best when you already own the OTP UI and just want Didit to send and
validate the code plus return the risk signals.
Two endpoints, both authenticated with x-api-key:
POST https://verification.didit.me/v3/email/send/
Body (application/json):
- email (required, string — RFC 5322 address)
- language (optional, ISO 639-1 code — picks the email template)
- vendor_data (optional string, your user id)
Returns: { reference_id }
POST https://verification.didit.me/v3/email/check/
Body (application/json):
- reference_id (required, from /email/send/)
- code (required, 6-digit string the user typed)
Returns: the full email-verification report (see Section 4).
Use the same vendor_data on retries so cross-session matches work.
## 3. Webhooks (Path A only — Path B returns synchronously)
- Register a webhook destination once via
POST https://verification.didit.me/v3/webhook/destinations/
Body: url, subscribed_events: ["session.verified",
"session.review_started",
"session.declined"]
- Response includes secret_shared_key — store it.
- Every webhook delivery carries an X-Signature-V2 header you MUST verify
before trusting the payload. HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature.Algorithm:
1. sortKeys(payload) recursively
2. shortenFloats (truncate trailing zeros after the decimal point)
3. JSON.stringify the result
4. HMAC-SHA256 with the secret_shared_key
5. Hex-encode, compare to the X-Signature-V2 header.
Two module-level event types fire alongside the session events above:
- EMAIL_VERIFICATION_MESSAGE_SENT — OTP was dispatched
- EMAIL_VERIFICATION_DECLINED — verification finished with a
Declined status (caller should
surface the warning to the user)
## 4. Reading the report (both paths return the same shape)
The email object includes:
- status: "Approved" | "Declined" | "In Review" | "Not Finished"
- email: the address that was verified
- is_breached: boolean — true when the address appears in known breaches
- breaches: array of { name, domain, logo_path, breach_date,
description, is_verified, data_classes,
breach_emails_count }
- is_disposable: boolean — true for throwaway providers
- is_undeliverable: boolean — true when MX + SMTP probe failed
- verification_attempts: number — OTP attempts used (max 2)
- verified_at: ISO 8601 timestamp
- matches: array of cross-session hits, each carrying session_id,
session_number, vendor_data, verification_date, email,
status, is_blocklisted
- warnings: Array<{ risk, additional_data, log_type,
short_description, long_description }>
Auto-decline risks (always enforced by Didit, not configurable):
- EMAIL_CODE_ATTEMPTS_EXCEEDED
- EMAIL_IN_BLOCKLIST
- UNDELIVERABLE_EMAIL_DETECTED
Configurable risks (action per workflow — Decline, Review, or Approve):
- BREACHED_EMAIL_DETECTED (exposure / breach intelligence)
- DISPOSABLE_EMAIL_DETECTED (temporary / throwaway provider)
- DUPLICATED_EMAIL (cross-session match on another user)
Anti-abuse limits (enforced server-side):
- Code Entry Attempts: max 2 tries to type the right OTP
- Code Resend Requests: max 2 resends per 24 hours
- Code Validity: 5 minutes from delivery
## 5. Chaining Email Verification into a KYC flow
EMAIL_VERIFICATION is a regular feature inside the Workflow Builder, so
it composes with any of the 25+ other modules. The canonical patterns:
- Cheap pre-filter: gate KYC behind Email Verification so disposable +
breached + undeliverable signups never burn a $0.33 KYC bundle. Use a
conditional branch — if status is Declined on email, skip
ID_VERIFICATION + LIVENESS + FACE_MATCH.
- Compliance log: keep Email Verification in the flow even when KYC is
the primary check, so the verified email is timestamped and signed
alongside the ID Verification report for Anti-Money Laundering (AML) (anti-money laundering)
recordkeeping.
- Step-up auth: rerun Email Verification at a sensitive action (large
withdrawal, password reset) using the same workflow + vendor_data
for closed-loop continuity.
## 6. Hard rules — do not change
- Base URL for /v3/* endpoints is verification.didit.me (NOT apx.didit.me).
- Feature enum is UPPERCASE: EMAIL_VERIFICATION, ID_VERIFICATION,
LIVENESS, FACE_MATCH, AML, IP_ANALYSIS, PHONE_VERIFICATION.
- Auth header is x-api-key (lowercase, hyphenated).
- Webhook signature header is X-Signature-V2 (NOT X-Signature).
- Always verify webhook signatures before trusting payload data.
- Status casing matches exactly: "Approved", "Declined", "In Review",
"Not Finished" (title-cased, space-separated).
## 7. Pricing reference (public)
- Email Verification: $0.03 per check (Path A or Path B).
- Bundled inside a full KYC workflow: same $0.03 add-on — the $0.33
full-KYC bundle does not include EMAIL_VERIFICATION by default.
- 500 free checks every month, forever, on every account.
## 8. Verify your integration
- Sandbox starts on signup at https://business.didit.me — no separate flag.
- Test emails: deterministic synthetic addresses returned in sandbox
(Approved by default; trigger Declined by sending the canonical
disposable / breached test addresses listed in the docs).
- Switch to live: flip the application's environment toggle in console.
When in doubt: https://docs.didit.me/core-technology/email-verification/overview
每月 $0。无需信用卡。
按实际用量付费。25+模块。公开的模块定价,无每月最低费用。
定制MSA和SLA。适用于大批量和受监管项目。
免费开始 → 仅在检查运行时付费 → 解锁企业版以获取定制合约、SLA 或数据驻留。
Didit是身份和欺诈基础设施, 是我们自己构建产品时希望存在的平台:开放、灵活且对开发者友好,因此它能真正融入您的技术栈,而不是一个需要您围绕其集成的黑盒。
一个API涵盖了验证个人(KYC,了解您的客户)、验证企业(KYB,了解您的业务)、筛选加密钱包(KYT,了解您的交易)以及实时监控交易, 构建在以下技术栈之上:
底层支持:14,000多种文档类型,支持48种以上语言,1,000多个数据源,每个会话200多个欺诈信号。Didit基础设施从每个会话中动态学习,并日益完善。
is_disposable、is_breached、is_undeliverable)形式呈现,并在warnings数组下附带类型化警告。email对象,包含status(Approved、Declined、In Review、Not Finished)、已验证的email、is_breached、一个breaches数组(每个条目:name、domain、logo_path、breach_date、description、is_verified、data_classes、breach_emails_count)、is_disposable、is_undeliverable、verification_attempts、verified_at(ISO 8601)、一个matches数组,包含跨会话匹配项,其中有session_id / vendor_data / verification_date / is_blocklisted,以及一个warnings数组(每个条目:risk、additional_data、log_type、short_description、long_description)。路径A(工作流)和路径B(独立)的格式相同。整个流程通常在30秒内完成, 拿起身份证件,拍摄证件,自拍,搞定。这是市场上最快的速度。传统的KYC提供商完成同样流程通常需要90秒以上。
在后端,从用户完成自拍到您的webhook触发,Didit在p99下两秒内返回结果。移动端捕获针对慢速手机和慢速网络进行了优化:渐进式图像压缩、延迟加载SDK,以及如果用户从网页端开始,可通过二维码一键从桌面端切换到手机端。
EMAIL_CODE_ATTEMPTS_EXCEEDED、EMAIL_IN_BLOCKLIST和UNDELIVERABLE_EMAIL_DETECTED进行硬性自动拒绝, 无论如何都在服务器端强制执行。(2) 对BREACHED_EMAIL_DETECTED、DISPOSABLE_EMAIL_DETECTED和DUPLICATED_EMAIL进行可配置的拒绝/审查/批准。(3) SMTP探测中的全方位和基于角色的检测, 在OTP发送之前进行标记。(4) 重发速率限制为每24小时2次,验证码输入尝试次数上限为2次, 均按会话计算。(5) 跨会话matches数组,显示在不同vendor_data中重复使用的相同电子邮件,从而防止重复账户农场。每个会话都会落入七种明确状态之一,因此您的代码始终知道如何处理:
Approved, 所有检查通过。让用户继续。Declined, 一项或多项检查失败。您可以允许用户重新提交特定失败步骤(例如,重新自拍),而无需重新运行整个流程。In Review, 标记为合规审查。在控制台中打开案例,查看所有信号,决定批准或拒绝。In Progress, 用户正在进行中。Not Started, 链接已发送,用户尚未打开。如果长时间未打开,发送提醒。Abandoned, 用户打开了链接但未及时完成。重新激活或使其过期。Expired, 会话链接已过期。创建新会话。每次状态更改都会触发一个带签名的webhook,因此您的数据库始终保持同步。放弃和拒绝的会话是免费的。
生产数据默认在欧盟的Amazon Web Services上处理和存储。企业合同可根据监管要求申请其他区域。
全面加密。 所有数据库、对象存储和备份均采用AES-256静态加密。所有API调用、webhook和业务控制台会话均采用传输层安全协议1.3进行传输加密。生物识别数据使用单独的客户主密钥加密。
保留期限由您控制。 默认保留期限为无限期(无限制),除非您配置更短的期限, 每个应用程序可在30天到10年之间选择, 您可以随时通过仪表板或API删除任何单个会话。
认证:SOC 2 Type 1(Type 2审计进行中)、ISO/IEC 27001:2022、iBeta Level 1 PAD,以及西班牙Tesoro / SEPBLAC / CNMV的公开证明,表明Didit的远程身份验证比亲自验证更安全。完整报告请访问/security-compliance。
Didit 默认符合身份基础设施相关监管机构的合规要求:
详细备忘录、所有证书、所有监管机构函件:/security-compliance。
三种集成路径, 选择最适合您技术栈的方式:
所有三种方式都使用相同的仪表板、相同的计费和相同的按成功付费价格。分步指南请访问 docs.didit.me/integration/integration-prompt。