跳到主要内容
Didit 融资200万美元并加入 Y Combinator (W26)
Didit
开发者

集成
身份和欺诈的最佳方式。

打开沙盒,粘贴一个curl命令,5分钟内即可上线。公开文档,五个软件开发工具包 (SDK),以及一个模型上下文协议 (MCP) 服务器,以便人工智能 (AI) 编码代理可以为您集成Didit。每次完整的KYC检查$0.33,每月免费500次。

支持者
Y Combinator
GBTC Finance
Bondex
Crnogorski Telekom
UCSF Neuroscape
Shiply
Adelantos

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

快速开始

五分钟内完成验证。

从注册到第一个验证用户只需五步。每一步都将业务控制台路径与程序化应用程序编程接口 (API) 路径配对。或者跳过所有步骤 — 将集成提示粘贴到您的AI编码代理中,网址为docs.didit.me/integration/integration-prompt。
01 · 注册

创建您的Didit账户。

  • 在业务控制台中: 在不到六十秒内通过 business.didit.me 注册 — 无需银行卡,无销售门槛。
  • 通过应用程序编程接口 (API): 调用 POST https://apx.didit.me/auth/v2/programmatic/register/,然后调用 POST .../verify-email/

无论哪种方式,您都将获得一个沙盒API密钥 — 与生产环境相同,所有模块均已解锁。

程序化注册API
生产 API 密钥
实时
didit_sk_live_8f4c2a…9bf3

刚刚发布 — 无需银行卡、合同、电话。

  • 无最低消费
  • 无合同
  • 500 次免费/月
  • 开放沙盒
02 · 构建工作流

选择模块。组合工作流。

  • 在业务控制台中: 将模块拖放到工作流构建器中 — 身份文档验证、被动活体检测、人脸匹配、反洗钱 (AML)、钱包筛选、互联网协议 (IP) 分析,以及其他19个模块。
  • 通过API:verification.didit.me 上使用您想要的模块调用 POST /v3/workflows/

无论哪种方式,都将返回一个 workflow_id,您将在每个会话中传递该ID。

创建工作流API
工作流程kyc-onboarding-v3
220+ 个国家/地区
  • ID Verification
  • Passive Liveness
  • Face Match 1:1
  • AML Screening
  • Device & IP Analysis
  • 地址证明
  • NFC 读取
  • 电话验证
  • 钱包筛选
  • 自定义问卷
+ 15 个以上模块 · 1,000+ 数据源$0.33/会话
03 · 注册Webhook

为每个结果配置一个网络钩子目标。

  • 在业务控制台中: 添加您的Webhook统一资源定位符 (URL),选择事件,并复制Didit生成的签名密钥。
  • 通过API: 使用 labelurlsubscribed_events 调用 POST /v3/webhook/destinations/。响应将返回Didit用于签署每次交付的 secret_shared_key
创建网络钩子目标API
REST · OpenAPI 3
docs.didit.me
  • POST/v3/session/
  • GET/v3/session/{id}/decision/
  • PATCH/v3/session/{id}/update-status/
  • GET/v3/session/{id}/generate-pdf
  • POST/v3/lists/{id}/entries/face-upload/
  • POST/v3/transactions/

每个端点开放 · 每个 webhook 均经过 HMAC 签名。

04 · 集成到您的应用中

创建会话——软件开发工具包 (SDK) 或直接API。

  • 使用软件开发工具包 (SDK): 嵌入适用于Web、iOS、Android、React Native或Flutter的原生SDK — 底层是相同的 /v3/ 契约。
  • 通过API: 使用 workflow_idvendor_data 值(您的用户标识符)调用 POST /v3/session/

响应将为您提供一个验证URL,用于重定向或嵌入到您的应用程序中。

查看SDK
POSThttps://verification.didit.me/v3/session/
curl
$ curl -X POST /v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "3daf4c64-...",
    "vendor_data": "u_42",
    "回调": "https://acme.com/webhook"
  }'
201已创建
{ "会话ID": "4c5c7f3a-...", "网址": "verify.didit.me/..." }
05 · 接收结果

监听网络钩子——或轮询。

  • 实时网络钩子: 您的端点会在每次状态更改时触发。读取 status"Approved""Declined""In Review""Resubmitted" 等),更新您的数据库,然后发货。
  • 通过轮询: 调用 GET /v3/session/:session_id/decision/ 获取相同的有效负载——当您的堆栈无法接受入站流量时非常有用。

状态字符串精确且区分大小写。完整的状态机请访问 docs.didit.me/integration/verification-statuses

验证状态
事件
live
  • session.verified2.4s ago200 OK
  • session.review_started12s ago200 OK
  • session.aml_hit1m ago200 OK
  • session.declined3m ago200 OK
使用Didit构建

所有界面公开。零销售电话。

阅读文档,调用应用程序编程接口 (API),插入模型上下文协议 (MCP) 服务器,粘贴集成提示,或发布预构建的代理技能 — 所有这些都是公开的,全部免费。
文档

查找每个模块、端点和 webhook。

快速入门

在 5 分钟内发布 KYC 流程。

API 参考

阅读 OpenAPI 3.1 规范。

SDKs

嵌入到 Web、iOS、Android、React Native 或 Flutter 中。

Webhooks

在每次状态更改时接收 HMAC 签名的事件。

验证状态

阅读完整的会话状态机。

集成提示

粘贴一个提示。发布 KYC 集成。

MCP 服务器

将 Didit 插入任何 MCP 客户端。

代理技能

预构建的验证、AML 和 KYB 技能。

五分钟集成

一个curl。五个SDK。

通过一个curl启动验证会话,或将流程嵌入到Web、iOS、 Android、React Native或Flutter中——底层都是相同的/v3/契约。
POSThttps://verification.didit.me/v3/session/
curl
$ curl -X POST /v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "3daf4c64-...",
    "vendor_data": "u_42",
    "回调": "https://acme.com/webhook"
  }'
201已创建
{ "会话ID": "4c5c7f3a-...", "网址": "verify.didit.me/..." }
Webv1.4.0iOSv3.0.1Androidv2.6.2
React Nativev1.8.0Flutterv1.3.4
面向开发者 · 面向AI代理 · 开放式设计

专为开发者和AI代理构建。

通过一个应用程序编程接口 (API) 集成Didit身份和欺诈检查。打开沙盒,阅读公开文档,插入模型上下文协议 (MCP) 服务器,或为任何堆栈拉取软件开发工具包 (SDK)。开发者可以在一个下午内完成上线;AI编码代理只需一个提示即可上线 — 无需用户界面,无需人工干预,无需销售电话,无最低要求。
01 · 一个API

用于身份和欺诈的一个API。

一个应用程序编程接口 (API) 涵盖所有身份和欺诈检查——了解您的客户 (KYC)、了解您的业务 (KYB)、反洗钱 (AML)、交易监控、生物识别匹配。相同的密钥,相同的工作流引擎,可在单个会话中链接——产品之间无需额外的集成工作。
阅读API文档
POSThttps://verification.didit.me/v3/session/
curl
$ curl -X POST /v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "3daf4c64-...",
    "vendor_data": "u_42",
    "回调": "https://acme.com/webhook"
  }'
201已创建
{ "会话ID": "4c5c7f3a-...", "网址": "verify.didit.me/..." }
02 · 代理原生

在单个提示中集成。

我们的模型上下文协议 (MCP) 服务器已上线,代理技能已发布。请Claude Code、Codex或Cursor集成Didit——代理会创建工作区、配置工作流并自行发送第一个API调用。没有仪表板,没有人工,没有支持工单。
阅读集成提示
promptdidit-integration.md
# Integrate Didit into my application

You are integrating Didit — infrastructure for identity and fraud — into my application end-to-end. Didit ships KYC, KYB, AML screening, biometric verification, transaction monitoring, and wallet screening behind one API. 220+ countries, 14,000+ document types, 48+ languages. Pay-per-call from $0.33, 500 free verifications per core feature per month, no minimums, no contract.

## My application context

<my_stack>
Stack: [framework + language — e.g. Next.js 15 + TypeScript, Django, Rails, Go]
Surface: [web | iOS | Android | React Native | Flutter | backend-only]
Use case: [KYC at signup | KYB at business onboarding | age gate | re-auth | transaction monitoring | other]
Database: [Postgres | MySQL | Mongo | other]
</my_stack>

## Step 1 — Create the Didit account programmatically

Two API calls. No browser. No 2FA. Returns an `api_key` you use for every subsequent request.

```bash
# 1) Register — creates org + app + emails a 6-character code
curl -X POST https://apx.didit.me/auth/v2/programmatic/register/   -H "Content-Type: application/json"   -d '{"email": "dev@example.com", "password": "StrongP@ss1"}'

# 2) Verify email with the code from the inbox — returns api_key
curl -X POST https://apx.didit.me/auth/v2/programmatic/verify-email/   -H "Content-Type: application/json"   -d '{"email": "dev@example.com", "code": "A3K9F2"}'
# Response.application.api_key — save this
```

Persist the returned `api_key` as the env var `DIDIT_API_KEY`. Auth header for every Didit call:
`x-api-key: $DIDIT_API_KEY`

## Base URLs

| Surface | Base URL |
|---|---|
| Every `/v3/...` endpoint (sessions, workflows, lists, billing, webhook destinations, entities, transactions, standalone APIs) | `https://verification.didit.me` |
| Auth / programmatic registration (`/auth/v2/programmatic/...`) | `https://apx.didit.me` |
| Console (human UI) | `https://business.didit.me` |
| Hosted verification URL handed to end users | `https://verify.didit.me` |
| Docs (cross-check anything) | `https://docs.didit.me` |
| OpenAPI spec (machine-readable, server is `https://verification.didit.me`) | `https://docs.didit.me/openapi-25.json` |

## Step 2 — Choose the integration approach

Pick exactly one, based on my use case:

- **Approach A — Sessions API + SDK (recommended for any end-user verification flow).** My backend creates a Didit session → my frontend opens the Didit-hosted verification UI (via SDK / iframe / redirect) → user completes verification → my backend receives a webhook with the decision. Best for KYC at signup, KYB at business onboarding, age verification, re-auth. Didit-hosted flows are A/B-tested and convert higher than custom UIs.
- **Approach B — Standalone APIs (server-to-server only).** My backend calls individual modules directly (`/v3/id-verification/`, `/v3/aml/`, `/v3/face-match/`, etc.) for batch jobs or fully custom UI. Best for back-office verification pipelines.

If unsure, default to Approach A.

## Step 3 — Create or reuse a workflow

A workflow defines which modules run during a session. Create one via API (or `https://business.didit.me` → Workflows → Create).

```bash
# List existing workflows
curl https://verification.didit.me/v3/workflows/   -H "x-api-key: $DIDIT_API_KEY"

# Create a new KYC workflow — features are UPPERCASE enum values, each an object with optional `config`
curl -X POST https://verification.didit.me/v3/workflows/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "workflow_label": "Standard KYC",
    "features": [
      { "feature": "OCR" },
      { "feature": "LIVENESS", "config": { "face_liveness_method": "PASSIVE" } },
      { "feature": "FACE_MATCH" },
      { "feature": "IP_ANALYSIS" }
    ]
  }'
# Response.uuid — save as DIDIT_WORKFLOW_ID
```

Feature enum values (UPPERCASE, source: `management-api/workflows/feature-configs.mdx`):
- **KYC features:** `OCR`, `NFC`, `LIVENESS`, `FACE_MATCH`, `AGE_ESTIMATION`, `PHONE_VERIFICATION`, `EMAIL_VERIFICATION`, `DATABASE_VALIDATION`, `AML`, `IP_ANALYSIS`, `PROOF_OF_ADDRESS`, `QUESTIONNAIRE`.
- **KYB features:** `KYB_REGISTRY`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE` (each plus AML / DATABASE_VALIDATION as needed).

For a KYB workflow set `"workflow_type": "kyb"` (default is KYC). A workflow is locked to its type at creation; create separate workflows per kind.

## Step 4 — Install the SDK that matches my stack

| Stack | Package | Install |
|---|---|---|
| Web (React, Vue, Next.js, Nuxt, Svelte, vanilla JS) | `@didit-protocol/sdk-web` | `npm install @didit-protocol/sdk-web` |
| iOS (Swift / SwiftUI) | `didit-sdk-ios` | SPM: `https://github.com/didit-protocol/didit-sdk-ios` |
| Android (Kotlin / Jetpack Compose) | `me.didit:didit-sdk` | Maven |
| React Native (Expo or bare) | `@didit-protocol/sdk-react-native` | `npm install @didit-protocol/sdk-react-native` |
| Flutter | `didit_sdk` | `flutter pub add didit_sdk` |
| Backend-only / batch / custom UI | none — call REST directly | — |

Always prefer native iOS / Android SDKs over WebView on mobile (NFC + camera + biometrics work natively).

## Step 5 — Create a session and present it to the user

**Backend creates the session:**

```bash
curl -X POST https://verification.didit.me/v3/session/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "workflow_id": "'"$DIDIT_WORKFLOW_ID"'",
    "vendor_data": "internal-user-id",
    "callback": "https://myapp.com/done"
  }'
```

Response (201 Created):
```json
{
  "session_id": "4c5c7f3a-...",
  "session_token": "eyJ...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "session_kind": "user",
  "workflow_id": "...",
  "vendor_data": "internal-user-id"
}
```

`vendor_data` is **my internal user ID** — Didit links the session to a User entity (auto-created if new). For KYB workflows it links to a Business entity.

Optional create-session field: `callback_method` (`"initiator"` | `"completer"` | `"both"`, default `"initiator"`) — controls which side of a cross-device flow receives the `callback` redirect. Useful when the verification opens on a phone after a desktop start.

**Frontend presents the verification (pick one):**

| Pattern | Code |
|---|---|
| Web JS SDK (modal) | `import { DiditSdk } from "@didit-protocol/sdk-web"; DiditSdk.shared.startVerification({ url })` |
| Iframe (embedded) | `<iframe src={url} allow="camera; microphone; fullscreen; autoplay; encrypted-media" />` |
| Redirect (cross-device) | `window.location.href = url` |
| iOS / Android / RN / Flutter | `DiditSdk.startVerification(token: session_token)` |

## Step 6 — Set up the webhook to receive results

Build `POST /api/webhooks/didit` in my backend.

**Register the webhook destination once:**

```bash
curl -X POST https://verification.didit.me/v3/webhook/destinations/   -H "x-api-key: $DIDIT_API_KEY"   -H "Content-Type: application/json"   -d '{
    "url": "https://myapp.com/api/webhooks/didit",
    "label": "production",
    "subscribed_events": ["status.updated", "data.updated"]
  }'
```

Response includes `secret_shared_key` — save as `DIDIT_WEBHOOK_SECRET`.

**Cloudflare / restrictive firewall users:** allowlist `18.203.201.92` — Didit webhooks egress from this single IP.

**Three signature headers** ship on every webhook. Verify **one** — `X-Signature-V2` is recommended because it survives JSON middleware re-encoding:

| Header | What it signs | When to use |
|---|---|---|
| `X-Signature-V2` ★ recommended | `JSON.stringify(sortKeys(shortenFloats(parsed_body)))` with unescaped Unicode | Default — works through Express / Django / FastAPI / Next.js body parsers |
| `X-Signature` | The raw request bytes verbatim | Only if you can guarantee no middleware re-encodes the body |
| `X-Signature-Simple` | `"{timestamp}:{session_id}:{status}:{webhook_type}"` | Fallback when nothing else works — does NOT verify the `decision` payload, so only use as a hint |

**Endpoint requirements (in order):**

1. Parse JSON (V2 is parser-tolerant; you can use any framework's default body parser).
2. Read headers: `X-Signature-V2` (HMAC-SHA256 hex), `X-Timestamp` (Unix seconds).
3. Reject if `abs(now - X-Timestamp) > 300` (replay protection).
4. Apply `shortenFloats` (whole-number floats → integers), then `sortKeys` (recursive lexicographic), then `JSON.stringify` (unescaped Unicode — default).
5. Compute `expected = HMAC-SHA256(DIDIT_WEBHOOK_SECRET, canonical_json, "utf8")`.
6. Compare with `X-Signature-V2` using constant-time comparison (`hmac.compare_digest` in Python, `crypto.timingSafeEqual` in Node).
7. Dispatch on `webhook_type`. Return `200` immediately even if processing is async — Didit retries 5xx/404 twice (~1 min, ~4 min).

**Node.js / Next.js App Router example (canonical V2):**

```ts
import crypto from "node:crypto";

// Server-side normalisation: convert whole-number floats to integers.
function shortenFloats(v: unknown): unknown {
  if (Array.isArray(v)) return v.map(shortenFloats);
  if (v && typeof v === "object") {
    return Object.fromEntries(
      Object.entries(v as Record<string, unknown>).map(([k, x]) => [k, shortenFloats(x)])
    );
  }
  if (typeof v === "number" && !Number.isInteger(v) && v % 1 === 0) return Math.trunc(v);
  return v;
}

// Recursively sort object keys (arrays preserved in order).
function sortKeys(v: unknown): unknown {
  if (Array.isArray(v)) return v.map(sortKeys);
  if (v && typeof v === "object") {
    return Object.keys(v as object)
      .sort()
      .reduce<Record<string, unknown>>((acc, k) => {
        acc[k] = sortKeys((v as Record<string, unknown>)[k]);
        return acc;
      }, {});
  }
  return v;
}

export async function POST(req: Request) {
  const raw = await req.text();
  const sig = req.headers.get("x-signature-v2") ?? "";
  const ts = Number(req.headers.get("x-timestamp"));
  if (!ts || Math.abs(Date.now() / 1000 - ts) > 300)
    return new Response("stale", { status: 401 });

  const parsed = JSON.parse(raw);
  const canonical = JSON.stringify(sortKeys(shortenFloats(parsed)));
  const expected = crypto
    .createHmac("sha256", process.env.DIDIT_WEBHOOK_SECRET!)
    .update(canonical, "utf8")
    .digest("hex");
  if (
    sig.length !== expected.length ||
    !crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(sig))
  )
    return new Response("bad sig", { status: 401 });

  // parsed.webhook_type → dispatch …
  return new Response("ok");
}
```

**Webhook event types:** `status.updated`, `data.updated`, `user.status.updated`, `user.data.updated`, `business.status.updated`, `business.data.updated`, `activity.created`, `transaction.created`, `transaction.status.updated`.

**Webhook body shape:**
```json
{
  "session_id": "uuid",
  "status": "Not Started | In Progress | Awaiting User | In Review | Approved | Declined | Resubmitted | Abandoned | Expired | Kyc Expired",
  "webhook_type": "status.updated",
  "timestamp": 1627680000,
  "workflow_id": "uuid",
  "vendor_data": "internal-user-id",
  "metadata": { "any": "json" },
  "decision": { /* present when Approved / Declined / In Review; absent on Expired / Abandoned / Not Started */ }
}
```

The `decision` object holds per-module **plural arrays** (V3 schema — each entry keyed by its `node_id` in the workflow):
- `id_verifications[]`: first_name, last_name, document_type, document_number, date_of_birth, nationality, expiration_date, issuing_state, address, parsed_address, mrz, front_image_quality_score, back_image_quality_score, warnings[]
- `nfc_verifications[]`: status, document_type, mrz, signature_status, chip_data
- `liveness_checks[]`: status, score (0–1), method ("passive" | "active"), reference_image
- `face_matches[]`: status, score (0–100), source_image, target_image, warnings[]
- `phone_verifications[]`: status, phone_number, carrier, is_disposable, is_virtual
- `email_verifications[]`: status, email, is_breached, is_disposable, is_undeliverable, breaches[]
- `poa_verifications[]`: status, document_type, issuer, poa_address, poa_parsed_address, issue_date, expiration_date
- `aml_screenings[]`: status, total_hits, hits[] (pep_matches, sanction_matches, warning_matches, adverse_media_matches), entity_type ("person" | "company")
- `ip_analyses[]`: status, ip_address, country, vpn, proxy, tor, hosting, risk_score
- `database_validations[]`: status, provider, match_type, fields_matched
- `questionnaire_responses`: nullable object keyed by question_id → answer

V2 → V3 migration note: V2 used singular keys (`aml`, `phone`, `email`, `poa`). V3 renamed them to plural arrays so a single workflow can run the same module multiple times on different nodes — index by `node_id`.

## Step 7 — Apply the decision to my database

```ts
switch (event.status) {
  case "Approved":       user.verified = true; user.verifiedAt = new Date(); storeDecision(event.decision); break;
  case "Declined":       user.verificationStatus = "declined"; logWarnings(event.decision); break;
  case "In Review":      user.verificationStatus = "pending_review"; break;
  case "In Progress":    user.verificationStatus = "in_progress"; break;
  case "Awaiting User":  user.verificationStatus = "awaiting_user"; break; // KYB only — waiting for a UBO / officer KYC sub-session
  case "Resubmitted":    user.verificationStatus = "resubmitted"; break; // reviewer asked the user to retry
  case "Abandoned":      scheduleReminderEmail(user); break;
  case "Expired":        break; // session URL aged out before the user finished
  case "Kyc Expired":    user.verified = false; createNewSession(user); break; // verified user's KYC has aged out per retention policy
  case "Not Started":    break;
}
```

Idempotency:
- Session webhooks: dedupe on `session_id + webhook_type + timestamp`.
- Transaction webhooks (`transaction.created`, `transaction.status.updated`): dedupe on the `event_id` field — multiple events can target the same transaction.

Didit retries 5xx/404 twice (~1 min, ~4 min after the prior failure). Return 200 even if processing is async.

## Module catalogue (use whichever ones match my use case)

| Module | Endpoint | Price | Free tier |
|---|---|---|---|
| Core KYC bundle (ID + Liveness + Face Match + IP) | session w/ workflow | **$0.33** | 500/mo (per feature) |
| ID Verification (standalone) | `POST /v3/id-verification/` | $0.20 | 500/mo |
| Passive Liveness (standalone) | `POST /v3/passive-liveness/` | $0.05 | 500/mo |
| Active Liveness | session-only | $0.15 | — |
| Face Match 1:1 | `POST /v3/face-match/` | $0.05 | 500/mo |
| Face Search 1:N | `POST /v3/face-search/` | $0.05 | — |
| Age Estimation | `POST /v3/age-estimation/` | $0.10 | — |
| AML Screening | `POST /v3/aml/` | $0.20 | — |
| Ongoing AML Monitoring | org-level continuous (per active user/yr) | $0.07 / user / year | — |
| Database Validation (gov registries) | `POST /v3/database-validation/` | variable | — |
| Proof of Address | `POST /v3/poa/` | $0.20 | — |
| Email Verification | `POST /v3/email/send/` + `POST /v3/email/check/` | $0.03 | — |
| Phone Verification (SMS / WhatsApp / voice / RCS / Telegram) | `POST /v3/phone/send/` + `POST /v3/phone/check/` | $0.04 + carrier | — |
| NFC Verification (native SDKs only) | session module | $0.15 | — |
| Biometric Authentication (re-auth) | session module | $0.10 | — |
| Device & IP Analysis | session module | $0.03 | — |
| Custom Questionnaire | session module | $0.10 | — |
| Business Verification (KYB) | `POST /v3/session/` w/ KYB workflow | $2.00 | — |
| Company AML Screening | KYB module | $0.20 | — |
| Person AML (per UBO / officer) | KYB module | $0.20 | — |
| Transaction Screening (rule engine) | `POST /v3/transactions/` | $0.02 / tx | — |
| AML Transaction Screening (counterparty sanctions + on-chain wallet risk) | inside `/v3/transactions/` | $0.15 / tx | — |
| Reusable KYC (share verified user across partners) | session feature | Free | — |
| White Label | workflow option | $0.20 | — |

## Operational APIs your code should know

| Action | Endpoint |
|---|---|
| Read full decision JSON | `GET /v3/session/{id}/decision/` |
| List sessions (filter by status, workflow, vendor_data, date) | `GET /v3/sessions` |
| Manually approve / decline / request review | `PATCH /v3/session/{id}/update-status/` |
| Patch metadata or extracted data | `PATCH /v3/session/{id}/update-data/` |
| Download compliance PDF | `GET /v3/session/{id}/generate-pdf` |
| Delete a session (GDPR / cleanup) | `DELETE /v3/session/{id}/delete/` |
| Share session with a partner (Reusable KYC) | `POST /v3/session/{id}/share/` |
| Submit a transaction for monitoring | `POST /v3/transactions/` |
| List / create lists (blocklist, allowlist, custom) | `GET/POST /v3/lists/` |
| Add entry to a list | `POST /v3/lists/{id}/entries/` |
| Upload a face image to a blocklist | `POST /v3/lists/{id}/entries/face-upload/` |
| Check credit balance | `GET /v3/billing/balance/` |
| Top up credits (returns Stripe checkout URL) | `POST /v3/billing/top-up/` |
| List / update / delete vendor users | `GET/PATCH /v3/users/`, `/v3/users/{vendor_data}/` |
| List / update / delete vendor businesses | `GET/PATCH /v3/businesses/` |

Every `/v3/...` endpoint above is served from `https://verification.didit.me` (the canonical OpenAPI server) and authenticates with `x-api-key`. Auth/registration is the only surface on `https://apx.didit.me`.

## Best-practice checklist before you mark this done

- [ ] `DIDIT_API_KEY`, `DIDIT_WORKFLOW_ID`, `DIDIT_WEBHOOK_SECRET` in env. Never committed.
- [ ] Backend route that creates a session for a given user, returns `url` (the hosted verification URL on `verify.didit.me`) and the `session_id`.
- [ ] Frontend that opens the session `url` via the right SDK / iframe / redirect for my stack.
- [ ] Webhook endpoint with: `X-Timestamp` freshness check (≤ 300s), canonical-V2 JSON re-serialisation (`shortenFloats` → `sortKeys` → unescaped `JSON.stringify`) HMAC-SHA256, constant-time compare against `X-Signature-V2`, dispatch on `webhook_type`, return 200.
- [ ] DB schema + update logic for `status in (Not Started, In Progress, Awaiting User, In Review, Approved, Declined, Resubmitted, Abandoned, Expired, Kyc Expired)`.
- [ ] Idempotent webhook handler (dedupe on `session_id + webhook_type`).
- [ ] No API key shipped to the browser. The session creation is server-side only.
- [ ] User-facing consent / disclosure shown BEFORE the session `url` opens (Didit handles biometric consent inside its flow but the legal layer outside is the integrator's responsibility).
- [ ] (Optional) `/v3/session/{id}/generate-pdf` surfaced in compliance UI.

## When you need more detail

- API root: `https://verification.didit.me/v3/` (everything `/v3/`). Auth only: `https://apx.didit.me/auth/v2/programmatic/register/`.
- Sessions overview: `https://docs.didit.me/sessions-api/overview`
- Standalone APIs index: `https://docs.didit.me/standalone-apis/id-verification`
- Programmatic registration: `https://docs.didit.me/integration/programmatic-registration`
- AI agent / MCP integration: `https://docs.didit.me/integration/ai-agent-integration`
- Webhooks reference: `https://docs.didit.me/integration/webhooks`
- SDKs overview: `https://docs.didit.me/integration/sdks`
- Full OpenAPI 3 spec: `https://docs.didit.me/openapi-25.json`
- MCP server config (drop into `.cursor/mcp.json`, `claude_desktop_config.json`, or equivalent):

```json
{
  "mcpServers": {
    "didit": {
      "command": "npx",
      "args": ["@didit-protocol/mcp-server"],
      "env": { "DIDIT_API_KEY": "your_api_key" }
    }
  }
}
```

The MCP server exposes 40+ tools spanning auth, sessions, workflows, questionnaires, users, billing, blocklist, and every standalone API — see `https://docs.didit.me/integration/ai-agent-integration` for the full tool catalogue.

Now build the integration. If anything in `## My application context` is missing, ask once at the top of your reply, then ship the complete change set: env vars wired, backend route, frontend SDK call, webhook endpoint with signature verification, decision-handling DB logic, and idempotent dedupe. Use my stack's idioms (`fetch` / `axios` / `requests` / `okhttp`), keep the API key server-side only, and follow the verification status state machine above.
粘贴到 Claude Code、Codex 或 Cursor 中 · 交付完整集成
03 · 模块化

任何流程。任何国家。任何用例。

从25+个模块、1,000+个政府数据源、220+个国家、14,000+种文档类型和48+种语言中组合任何流程。同一个协调器运行生物识别认证、新银行的KYC、B2B金融科技的KYB、加密货币交易所的旅行规则,或市场的持续AML——您选择检查和顺序。
查看所有模块
工作流程kyc-onboarding-v3
220+ 个国家/地区
  • ID Verification
  • Passive Liveness
  • Face Match 1:1
  • AML Screening
  • Device & IP Analysis
  • 地址证明
  • NFC 读取
  • 电话验证
  • 钱包筛选
  • 自定义问卷
+ 15 个以上模块 · 1,000+ 数据源$0.33/会话
04 · 自助服务

没有付费墙。没有销售电话。去玩吧。

沙盒从第一分钟起就开放。文档和API是公开的,您与代码之间没有演示门槛。注册,获取密钥,当天发货。我们的销售团队随时为您服务——绝不设限。
尝试沙盒
生产 API 密钥
实时
didit_sk_live_8f4c2a…9bf3

刚刚发布 — 无需银行卡、合同、电话。

  • 无最低消费
  • 无合同
  • 500 次免费/月
  • 开放沙盒
05 · 基于使用量

按使用量付费。就是这样。

Didit比现有KYC供应商便宜3-5倍,所有价格都在/pricing上公开——$0.33完整KYC捆绑包,$0.15钱包筛选,$0.03设备和IP分析,每月免费500次验证。没有最低消费,没有年度合同,没有超额意外——页面上的价格就是发票上的价格。
查看所有价格
公开价格表
/pricing
  • ID Verification$0.15
  • Passive Liveness$0.10
  • Face Match 1:1$0.05
  • AML Screening$0.20
  • Device & IP Analysis$0.03
  • 钱包筛选 (KYT)$0.15
完整 KYC 套餐$0.33

500 次免费/月 · 无最低消费 · 无年度合同。

06 · 开放基础设施

开放API。在此基础上构建。

每个端点都是开放且有文档的——更改会话状态、将人脸列入黑名单、下载决策PDF、编辑工作流或查询事件日志。Webhooks使用基于哈希的消息认证码 (HMAC) 签名,因此您可以证明每个事件都来自我们。Didit是基础设施,而不是封闭应用程序。
浏览API
REST · OpenAPI 3
docs.didit.me
  • POST/v3/session/
  • GET/v3/session/{id}/decision/
  • PATCH/v3/session/{id}/update-status/
  • GET/v3/session/{id}/generate-pdf
  • POST/v3/lists/{id}/entries/face-upload/
  • POST/v3/transactions/

每个端点开放 · 每个 webhook 均经过 HMAC 签名。

07 · SDK

适用于所有平台的 SDK。

适用于每个堆栈的软件开发工具包 (SDK) — Web、iOS、Android、React Native、Flutter。在后端,有 REST API、签名 Webhook、OpenAPI 3 规范以及现成的 Zapier、Shopify 和 Salesforce 集成。每个界面都附带示例、类型和 5 分钟入门指南。
浏览 SDK
Webv1.4.0iOSv3.0.1Androidv2.6.2
React Nativev1.8.0Flutterv1.3.4
08 · 针对规模优化的基础设施

市场上最快的验证。

99% 的验证在 2 秒内端到端完成 — 在生产环境中衡量,而非在演示文稿中声称。我们的目标是 99.99% 的服务水平协议 (SLA),在过去 12 个月内保持 100% 的正常运行时间,并且从未被攻破。针对每种设备和网络进行了优化 — iPhone、Android、台式机、平板电脑、5G 或 2G — 并且每月已运行数百万次验证。
查看实时状态
端到端延迟 · 30 天
99.99% SLA
  • p500.82s
  • p951.42s
  • p991.89s

市场上最快的验证 · iPhone、Android、桌面、平板电脑、5G 或 2G。

三个层级,一个价目表

免费开始。按使用量付费。扩展到企业版。

每月永久免费500次验证。生产环境按使用量付费。企业版提供定制合同、数据驻留和SLA(服务水平协议)。
免费

免费

每月$0。无需信用卡。

  • 免费KYC捆绑包(身份验证 + 被动活体检测 + 人脸匹配 + 设备和IP分析)——每月500次,永久有效
  • 黑名单用户
  • 重复检测
  • 每次会话200+欺诈信号
  • Didit网络中可重复使用的KYC
  • 案例管理平台
  • 工作流程构建器
  • 公开文档、沙盒、SDK、MCP(模型上下文协议)服务器
  • 社区支持
最受欢迎
按使用量付费

按使用量付费

只为您使用的付费。25+ 模块。公开的按模块定价,无每月最低费用。

  • 全套 KYC,价格 $0.33(身份证明 + 生物识别 + IP / 设备)
  • 10,000+ AML 数据集 — 制裁、PEP、负面媒体
  • 1,000+ 政府数据源用于数据库验证
  • 交易监控,每笔交易 $0.02
  • 实时 KYB,每个企业 $2.00
  • 钱包筛选,每次检查 $0.15
  • 白标验证流程 — 您的品牌,我们的基础设施
企业版

企业版

定制 MSA 和 SLA。适用于大批量和受监管的项目。

  • 年度合同
  • 定制 MSA、DPA 和 SLA
  • 专用 Slack 和 WhatsApp 频道
  • 按需人工审核员
  • 经销商和白标条款
  • 独家功能和合作伙伴集成
  • 指定 CSM、安全审查、合规支持

免费开始 → 仅在运行检查时付费 → 解锁企业版以获取定制合同、SLA或数据驻留。

FAQ

开发者问题,已解答。

我们在集成通话中发送给工程团队的相同答案。其他问题请发送至 support@didit.me。
我如何集成 Didit?

从注册到首次裁决的五个步骤。

  • business.didit.me 创建您的账户,或调用 POST https://apx.didit.me/auth/v2/programmatic/register/
  • 在业务控制台中构建工作流,或调用 POST /v3/workflows/
  • 通过控制台注册 webhook 目的地,或调用 POST /v3/webhook/destinations/(Didit 在响应中返回签名密钥)。
  • 使用 POST /v3/session/ 创建会话,传入 workflow_idvendor_data(您的用户标识符)。将用户重定向到返回的 URL——或在相同的 /v3/ 契约上放入原生软件开发工具包 (SDK)。
  • 在已签名的 webhook 上接收裁决,或轮询 GET /v3/session/:session_id/decision/

一个 /v3/ 应用程序编程接口 (API) 涵盖了了解您的客户 (KYC)、了解您的业务 (KYB)、交易监控和钱包筛选 (KYT——了解您的交易)。每月免费 500 次验证,永久有效,无需信用卡。

现在有我可以玩的沙盒吗?

是的——不到六十秒,无需信用卡。business.didit.me 注册(或通过 POST https://apx.didit.me/auth/v2/programmatic/register/ 以编程方式注册),您将进入一个带有真实应用程序编程接口 (API) 密钥的沙盒工作区。

  • 与生产环境相同的形式——确定性决策,所有模块均已解锁。
  • 真实的 /v3/ 端点、真实的 webhook、真实的文档示例。
  • 准备就绪后即可切换到实时环境——相同的密钥、相同的统一资源定位符 (URL)、相同的合同。
你们提供哪些软件开发工具包 (SDK)?

五个第一方 SDK,全部开源,全部在公开文档中:

  • Web——JavaScript / TypeScript,与框架无关,iframe 嵌入或托管流程重定向。
  • iOS——Swift,以 XCFramework 形式分发。
  • Android——Kotlin,通过 Maven Central。
  • React Native——基于原生模块 (TurboModules) 的 TypeScript 绑定。
  • Flutter——围绕相同原生 SDK 的 Dart 包装器。

每个 SDK 在底层都调用相同的 /v3/ 契约,因此您可以混合搭配——您的网站上使用 Web,移动设备上使用原生。参考资料请访问 docs.didit.me/integration/web-sdks/overview

Webhook 如何工作?

注册一个目的地;Didit 会签署每次交付。

  • 通过业务控制台配置您的端点——或使用 labelurlsubscribed_events 调用 POST /v3/webhook/destinations/
  • Didit 在响应中返回 secret_shared_key。使用它来验证每个传入 webhook 上的基于哈希的消息认证码 (HMAC)-SHA256 签名(标头:X-Signature-V2)。
  • 每个有效负载都带有精确的、区分大小写的 status——"Approved"(已批准)、"Declined"(已拒绝)、"In Review"(审核中)、"Resubmitted"(已重新提交)等等。完整的状态机请访问 docs.didit.me/integration/verification-statuses
  • 重试使用指数退避,直到您返回 2xx;每次交付都会记录,并可从控制台按需重放

完整参考资料请访问 docs.didit.me/integration/webhooks

速率限制是多少,大规模使用时会发生什么?

所有计划均提供慷慨的默认设置,并可根据账户向上调整。

  • 免费套餐 — 沙盒以及每月500次生产检查,永久有效
  • 按使用量付费 — 突发限制会随持续的流量自动扩展。您不会在发布中途遇到瓶颈。
  • 企业版 — 在主服务协议 (MSA) 中提供自定义速率限制、专用容量和正常运行时间承诺。请通过 support@didit.me 联系我们。

status.didit.me 上每个区域的目标容量。在过去6个月中,每月数百万次验证的100%真实正常运行时间

我可以与Claude Code、Cursor或其他AI编码工具集成吗?

可以 — 粘贴一个提示即可发布。docs.didit.me/integration/integration-prompt 上的规范集成提示放入Claude Code、Cursor、Codex、Devin、Aider或Replit Agent中。代理会配置工作流程,连接webhook,并运行端到端的冒烟测试。

代理发起的会话支付与直接API调用相同的公开价格 — 每次完整的“了解您的客户 (KYC)” $0.33,每次独立的身份文件验证 $0.15,每次钱包筛选 $0.15。免费,无需额外设置,适用于任何支持模型上下文协议 (MCP) 的客户端。

更新日志在哪里,以及您如何对API进行版本控制?

`docs.didit.me/changelog` 上每月发布发布说明 — 每一个已发布的模块,每一个添加的webhook事件,每一个指出的重大变更。

  • docs.didit.me/openapi-25.json 上的 OpenAPI 3.1 规范与文档一起进行版本控制。将其导入Postman或用任何语言生成客户端。
  • 版本控制默认是增量的。新字段、新的可选参数和新的webhook事件在不增加版本号的情况下发布。重大变更会获得一个新的 /v4/ 命名空间和已发布的弃用窗口。
  • 我们从不悄悄更改字段的含义 — 如果裁决形式、签名方案或状态枚举发生变化,它会在一个标头后面发布,并在切换前宣布。
我如何监控正常运行时间以及事件处理流程是什么?

`status.didit.me` 发布每个区域的实时正常运行时间和事件历史记录 — 验证、webhook、控制台、文档。无需登录。

  • 通过简易信息聚合 (RSS)、电子邮件或webhook订阅中断警报。
  • 记录:过去6个月100%真实正常运行时间;服务水平协议 (SLA) 中的99.99%可用性目标
  • 每个事件都会在同一页面上发布公开的事后分析。
  • 企业合同在主服务协议 (MSA) 中增加了指定的待命工程师、专用的Slack或Microsoft Teams共享频道以及事件严重性服务水平目标。

身份和欺诈基础设施。

一个用于 KYC、KYB、交易监控和钱包筛选的 API。5 分钟内即可集成。

让 AI 总结此页面