Trouvez chaque module, point de terminaison et webhook.
La meilleure façon d'intégrer
l<blue>identité et la fraude.</blue>
Ouvrez le bac à sable, collez un curl, et déployez en 5 minutes. Documentation publique, cinq Software Development Kits (SDKs), et un serveur Model Context Protocol (MCP) pour qu'un agent de codage d'Intelligence Artificielle (IA) puisse intégrer Didit pour vous. 0,33 $ par vérification KYC complète, 500 gratuites chaque mois.




Approuvé par plus de 2 000 organisations dans le monde entier.
De zéro à vérifié en cinq minutes.
Créez votre compte Didit.
- Dans la console d'entreprise : inscrivez-vous sur
business.didit.meen moins de soixante secondes — pas de carte, pas de barrière de vente. - Par interface de programmation d'applications (API) : appelez
POST https://apx.didit.me/auth/v2/programmatic/register/, puisPOST .../verify-email/.
L'un ou l'autre chemin vous laisse avec une clé API de bac à sable — même format que la production, chaque module déverrouillé.
Émis à l'instant — pas de carte, pas de contrat, pas d'appel.
- Pas de minimum
- Pas de contrat
- 500 gratuits / mois
- Bac à sable ouvert
Choisissez les modules. Composez le workflow.
- Dans la console d'entreprise : glissez-déposez les modules dans le Workflow Builder — Vérification de document d'identité, Liveness passif, Correspondance faciale, Lutte contre le blanchiment d'argent (AML), Filtrage de portefeuille, Analyse de protocole Internet (IP), et 19 autres.
- Par API : appelez
POST /v3/workflows/surverification.didit.meavec les modules que vous souhaitez.
L'un ou l'autre chemin renvoie un workflow_id que vous transmettrez à chaque session.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Preuve d'adresse
- Lecture NFC
- Vérification téléphonique
- Filtrage de portefeuille
- Questionnaire personnalisé
Configurez une destination de webhook pour chaque verdict.
- Dans la console d'entreprise : ajoutez l'Uniform Resource Locator (URL) de votre webhook, choisissez les événements et copiez le secret de signature généré par Didit.
- Par API : appelez
POST /v3/webhook/destinations/aveclabel,urletsubscribed_events. La réponse renvoie lasecret_shared_keyque Didit utilise pour signer chaque livraison.
- 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/
Chaque point de terminaison ouvert · chaque webhook signé HMAC.
Créez une session — Kit de développement logiciel (SDK) ou API directe.
- Avec un Software Development Kit (SDK) : intégrez le SDK natif pour Web, iOS, Android, React Native ou Flutter — même contrat
/v3/en dessous. - Par API : appelez
POST /v3/session/avec leworkflow_idet une valeurvendor_data(votre identifiant utilisateur).
La réponse vous donne une URL de vérification à rediriger ou à intégrer dans votre application.
$ 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",
"rappel": "https://acme.com/webhook"
}'Écoutez le webhook — ou interrogez.
- Webhook en temps réel : votre endpoint se déclenche à chaque changement d'état. Lisez le
status("Approved","Declined","In Review","Resubmitted", …), mettez à jour votre base de données, expédiez. - Par polling : appelez
GET /v3/session/:session_id/decision/pour la même charge utile — utile lorsque votre stack ne peut pas accepter le trafic entrant.
Les chaînes de statut sont exactes et sensibles à la casse. Machine d'état complète sur docs.didit.me/integration/verification-statuses.
- evt_9c2session.verified2.4s ago200 OK
- evt_9c1session.review_started12s ago200 OK
- evt_9c0session.aml_hit1m ago200 OK
- evt_9bfsession.declined3m ago200 OK
Toutes les surfaces, publiques. Zéro appel de vente.
Déployez un flux KYC en 5 minutes.
Lisez la spécification OpenAPI 3.1.
Intégrez sur le Web, iOS, Android, React Native ou Flutter.
Recevez des événements signés HMAC à chaque changement d'état.
Lisez la machine à états complète de la session.
Collez une invite. Déployez l'intégration KYC.
Connectez Didit à n'importe quel client MCP.
Compétences de vérification, AML et KYB pré-construites.
Un curl. Cinq SDKs.
$ 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",
"rappel": "https://acme.com/webhook"
}'Conçu pour les développeurs et les agents IA.
Une seule API pour l'identité et la fraude.
$ 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",
"rappel": "https://acme.com/webhook"
}'Intégrer en une seule invite.
# 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.
N'importe quel flux. N'importe quel pays. N'importe quel cas d'utilisation.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Preuve d'adresse
- Lecture NFC
- Vérification téléphonique
- Filtrage de portefeuille
- Questionnaire personnalisé
Pas de péage. Pas d'appel de vente. Allez jouer avec.
Émis à l'instant — pas de carte, pas de contrat, pas d'appel.
- Pas de minimum
- Pas de contrat
- 500 gratuits / mois
- Bac à sable ouvert
Payez pour ce que vous utilisez. C'est tout.
- ID Verification$0.15
- Passive Liveness$0.10
- Face Match 1:1$0.05
- AML Screening$0.20
- Device & IP Analysis$0.03
- Filtrage de portefeuille (KYT)$0.15
500 gratuits / mois · pas de minimum · pas de contrat annuel.
API ouverte. Construisez dessus.
- 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/
Chaque point de terminaison ouvert · chaque webhook signé HMAC.
SDK pour chaque plateforme.
Les vérifications les plus rapides du marché.
- p500.82s
- p951.42s
- p991.89s
Vérifications les plus rapides du marché · iPhone, Android, ordinateur de bureau, tablette, 5G ou 2G.
Commencez gratuitement. Payez à l'usage. Passez à l'Entreprise.
Gratuit
0 $ / mois. Aucune carte de crédit requise.
- Forfait KYC gratuit (Vérification d'identité + Vivacité passive + Correspondance faciale + Analyse d'appareil et IP) — 500 / mois, chaque mois
- Utilisateurs bloqués
- Détection des doublons
- Plus de 200 signaux de fraude sur chaque session
- KYC réutilisable sur le réseau Didit
- Plateforme de gestion des cas
- Constructeur de flux de travail
- Documentation publique, sandbox, SDK, serveur MCP (Model Context Protocol)
- Support communautaire
Basé sur l'utilisation
Payez uniquement pour ce que vous utilisez. Plus de 25 modules. Tarification publique par module, pas de frais mensuels minimums.
- KYC complet à 0,33 $ (ID + Biométrie + IP / Appareil)
- Plus de 10 000 ensembles de données AML — sanctions, PEP, médias défavorables
- Plus de 1 000 sources de données gouvernementales pour la validation de base de données
- Surveillance des transactions à 0,02 $ par transaction
- KYB en direct à 2,00 $ par entreprise
- Filtrage de portefeuille à 0,15 $ par vérification
- Flux de vérification en marque blanche — votre marque, notre infrastructure
Entreprise
MSA et SLA personnalisés. Pour les grands volumes et les programmes réglementés.
- Contrats annuels
- MSA, DPA et SLA personnalisés
- Canal Slack et WhatsApp dédié
- Examinateurs manuels sur demande
- Conditions de revendeur et de marque blanche
- Fonctionnalités exclusives et intégrations partenaires
- CSM désigné, examen de sécurité, support de conformité
Commencez gratuitement → payez uniquement lorsqu'une vérification est effectuée → débloquez l'Entreprise pour un contrat personnalisé, un SLA ou une résidence des données.
Questions des développeurs, répondues.
Comment intégrer Didit ?
Cinq étapes de l'inscription au premier verdict.
- Créez votre compte sur
business.didit.me, ou appelezPOST https://apx.didit.me/auth/v2/programmatic/register/. - Créez un workflow dans la console d'entreprise, ou appelez
POST /v3/workflows/. - Enregistrez une destination de webhook via la console, ou appelez
POST /v3/webhook/destinations/(Didit renvoie le secret de signature dans la réponse). - Créez une session avec
POST /v3/session/, en passantworkflow_idetvendor_data(votre identifiant utilisateur). Redirigez l'utilisateur vers l'URL renvoyée — ou intégrez un kit de développement logiciel (SDK) natif sur le même contrat/v3/. - Recevez le verdict sur le webhook signé, ou interrogez
GET /v3/session/:session_id/decision/.
Une seule API /v3/ couvre la connaissance client (KYC), la connaissance de votre entreprise (KYB), la surveillance des transactions et le filtrage des portefeuilles (KYT — connaissance de votre transaction). 500 vérifications gratuites chaque mois, pour toujours, sans carte de crédit.
Y a-t-il un sandbox avec lequel je peux jouer dès maintenant ?
Oui — en moins de soixante secondes, sans carte de crédit. Inscrivez-vous sur business.didit.me (ou inscrivez-vous par programme avec POST https://apx.didit.me/auth/v2/programmatic/register/) et vous accéderez à un espace de travail sandbox avec une véritable clé d'interface de programmation d'applications (API).
- Même forme que la production — décisions déterministes, chaque module débloqué.
- De vrais points de terminaison
/v3/, de vrais webhooks, de vrais exemples de documents. - Passez en direct quand vous êtes prêt — mêmes clés, mêmes localisateurs de ressources uniformes (URL), même contrat.
Quels kits de développement logiciel (SDK) proposez-vous ?
Cinq SDK propriétaires, tous open-source, tous sur la documentation publique :
- Web — JavaScript / TypeScript, agnostique au framework, intégration iframe ou redirection de flux hébergé.
- iOS — Swift, distribué en tant que
XCFramework. - Android — Kotlin, via Maven Central.
- React Native — liaisons TypeScript au-dessus des modules natifs (TurboModules).
- Flutter — wrapper Dart autour des mêmes SDK natifs.
Chaque SDK appelle le même contrat /v3/ en arrière-plan, vous pouvez donc mélanger et assortir — Web sur votre site, natif sur mobile. Référence sur docs.didit.me/integration/web-sdks/overview.
Comment fonctionnent les webhooks ?
Enregistrez une destination ; Didit signe chaque livraison.
- Configurez votre point de terminaison via la console d'entreprise — ou appelez
POST /v3/webhook/destinations/aveclabel,urletsubscribed_events. - Didit renvoie une
secret_shared_keydans la réponse. Utilisez-la pour vérifier la signature HMAC-SHA256 (Hash-based Message Authentication Code) sur chaque webhook entrant (en-tête :X-Signature-V2). - Chaque charge utile contient un
statusexact, sensible à la casse —"Approved","Declined","In Review","Resubmitted", et plus encore. Machine d'état complète surdocs.didit.me/integration/verification-statuses. - Les tentatives utilisent une rétention exponentielle jusqu'à ce que vous renvoyiez
2xx; chaque livraison est enregistrée et rejouable à la demande depuis la console.
Référence complète sur docs.didit.me/integration/webhooks.
Quelles sont les limites de débit, et que se passe-t-il à grande échelle ?
Des valeurs par défaut généreuses pour chaque plan, ajustées à la hausse par compte.
- Niveau gratuit — bac à sable plus 500 vérifications de production chaque mois, pour toujours.
- Paiement à l'usage — les limites de rafale s'adaptent automatiquement au volume soutenu. Vous ne rencontrerez pas de blocage en plein lancement.
- Entreprise — limites de débit personnalisées, capacité dédiée et engagements de disponibilité dans l'accord de services principal (MSA). Contactez-nous à
support@didit.me.
Capacité cible par région sur status.didit.me. 100 % de disponibilité réelle au cours des 6 derniers mois sur des millions de vérifications par mois.
Puis-je m'intégrer à Claude Code, Cursor ou d'autres outils de codage IA ?
Oui — collez une seule invite et déployez. Déposez l'invite d'intégration canonique de docs.didit.me/integration/integration-prompt dans Claude Code, Cursor, Codex, Devin, Aider ou Replit Agent. L'agent provisionne le flux de travail, câble le webhook et exécute un test de fumée de bout en bout.
Les sessions initiées par l'agent paient le même prix public que les appels API directs — $0.33 par Know Your Customer (KYC) complet, $0.15 par vérification de document d'identité autonome, $0.15 par examen de portefeuille. Gratuit, aucune configuration supplémentaire, fonctionne avec tout client compatible avec le protocole de contexte de modèle (MCP).
Où se trouve le journal des modifications et comment versionnez-vous l'API ?
Notes de version mensuelles sur `docs.didit.me/changelog` — chaque module livré, chaque événement de webhook ajouté, chaque changement cassant signalé.
- La spécification OpenAPI 3.1 sur
docs.didit.me/openapi-25.jsonest versionnée en même temps que la documentation. Importez-la dans Postman ou générez des clients dans n'importe quel langage. - Le versionnement est additif par défaut. Les nouveaux champs, les nouveaux paramètres optionnels et les nouveaux événements de webhook sont livrés sans augmentation de version. Les changements cassants obtiennent un nouvel espace de noms
/v4/et une fenêtre de dépréciation publiée. - Nous ne changeons jamais silencieusement la signification d'un champ — si la forme d'un verdict, le schéma de signature ou l'énumération de statut change, il est livré derrière un en-tête et annoncé avant la coupure.
Comment surveiller la disponibilité et quel est le processus d'incident ?
`status.didit.me` publie la disponibilité en temps réel et l'historique des incidents par région — vérification, webhooks, console, documentation. Aucune connexion requise.
- Abonnez-vous via Really Simple Syndication (RSS), e-mail ou webhook pour les alertes de panne.
- Historique : 100 % de disponibilité réelle au cours des 6 derniers mois ; objectif de disponibilité de 99,99 % dans l'accord de niveau de service (SLA).
- Chaque incident fait l'objet d'un post-mortem public sur la même page.
- Les contrats d'entreprise ajoutent un ingénieur d'astreinte désigné, un canal partagé Slack ou Microsoft Teams dédié, et des objectifs de niveau de service de gravité d'incident dans l'accord de services principal (MSA).
Infrastructure pour l'identité et la fraude.
Une seule API pour le KYC, le KYB, la surveillance des transactions et le filtrage des portefeuilles. Intégration en 5 minutes.