Troba cada mòdul, punt final i webhook.
La millor manera d'integrar
la identitat i el frau.
Obre l'entorn de proves, enganxa un curl i llança en 5 minuts. Documents públics, cinc kits de desenvolupament de programari (SDKs) i un servidor de Protocol de Context de Model (MCP) perquè un agent de codificació d'Intel·ligència Artificial (IA) pugui integrar Didit per tu. 0,33 $ per cada verificació KYC completa, 500 gratuïtes cada mes.




Confiat per més de 2.000 organitzacions a tot el món.
De zero a verificat en cinc minuts.
Creeu el vostre compte de Didit.
- A la Consola de Negocis: registra't a
business.didit.meen menys de seixanta segons — sense targeta, sense barrera de vendes. - Per Interfície de Programació d'Aplicacions (API): crida
POST https://apx.didit.me/auth/v2/programmatic/register/, desprésPOST .../verify-email/.
Qualsevol de les dues rutes et deixa amb una clau API de l'entorn de proves — amb la mateixa forma que la de producció, amb tots els mòduls desbloquejats.
Emès ara mateix — sense targeta, sense contracte, sense trucada.
- Sense mínim
- Sense contracte
- 500 gratuïts / mes
- Entorn de proves obert
Trieu els mòduls. Composeu el flux de treball.
- A la Consola de Negocis: arrossega i deixa anar els mòduls al Creador de Fluxos de Treball — Verificació de Documents d'Identitat, Prova de Vida Passiva, Coincidència Facial, Antilegalització de Diners (AML), Anàlisi de Carteres, Anàlisi de Protocol d'Internet (IP) i 19 més.
- Per API: crida
POST /v3/workflows/averification.didit.meamb els mòduls que desitgis.
Qualsevol de les dues rutes retorna un workflow_id que passaràs a cada sessió.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Prova d'adreça
- Lectura NFC
- Verificació telefònica
- Detecció de carteres
- Qüestionari personalitzat
Configureu una destinació de webhook per a cada veredicte.
- A la Consola de Negocis: afegeix la teva URL (Uniform Resource Locator) del webhook, tria els esdeveniments i copia el secret de signatura que Didit genera.
- Per API: crida
POST /v3/webhook/destinations/amblabel,urlisubscribed_events. La resposta retorna lasecret_shared_keyque Didit utilitza per signar cada lliurament.
- 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/
Cada punt final obert · cada webhook signat amb HMAC.
Creeu una sessió — Kit de desenvolupament de programari (SDK) o API directa.
- Amb un Kit de Desenvolupament de Programari (SDK): inclou l'SDK natiu per a Web, iOS, Android, React Native o Flutter — el mateix contracte
/v3/a sota. - Per API: crida
POST /v3/session/amb elworkflow_idi un valorvendor_data(el teu identificador d'usuari).
La resposta et proporciona una URL de verificació per redirigir o incrustar a la teva aplicació.
$ 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",
"callback": "https://acme.com/webhook"
}'Escolteu el webhook — o sondegeu.
- Webhook en temps real: el vostre punt final s'activa a cada canvi d'estat. Llegiu l'
status("Approved","Declined","In Review","Resubmitted", …), actualitzeu la vostra base de dades, envieu. - Per sondeig: truqueu a
GET /v3/session/:session_id/decision/per a la mateixa càrrega útil, útil quan la vostra pila no pot acceptar trànsit entrant.
Les cadenes d'estat són exactes i sensibles a majúscules i minúscules. Màquina d'estats completa a 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
Totes les superfícies, públiques. Zero trucades de vendes.
Envia un flux KYC en 5 minuts.
Llegeix l'especificació OpenAPI 3.1.
Insereix a Web, iOS, Android, React Native o Flutter.
Rep esdeveniments signats amb HMAC en cada canvi d'estat.
Llegeix la màquina d'estats completa de la sessió.
Enganxa una indicació. Envia la integració KYC.
Connecta Didit a qualsevol client MCP.
Habilitats de verificació, AML i KYB preconstruïdes.
Un curl. Cinc 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",
"callback": "https://acme.com/webhook"
}'Construït per a desenvolupadors i agents d'IA.
Una API per a la identitat i el frau.
$ 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",
"callback": "https://acme.com/webhook"
}'Integra en una sola indicació.
# 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.
Qualsevol flux. Qualsevol país. Qualsevol cas d'ús.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Prova d'adreça
- Lectura NFC
- Verificació telefònica
- Detecció de carteres
- Qüestionari personalitzat
Sense mur de pagament. Sense trucada de vendes. Ves a jugar-hi.
Emès ara mateix — sense targeta, sense contracte, sense trucada.
- Sense mínim
- Sense contracte
- 500 gratuïts / mes
- Entorn de proves obert
Paga pel que utilitzes. Això és tot.
- ID Verification$0.15
- Passive Liveness$0.10
- Face Match 1:1$0.05
- AML Screening$0.20
- Device & IP Analysis$0.03
- Detecció de carteres (KYT)$0.15
500 gratuïts / mes · sense mínim · sense contracte anual.
API oberta. Construeix a sobre.
- 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/
Cada punt final obert · cada webhook signat amb HMAC.
SDKs per a cada plataforma.
Les verificacions més ràpides del mercat.
- p500.82s
- p951.42s
- p991.89s
Verificacions més ràpides del mercat · iPhone, Android, escriptori, tauleta, 5G o 2G.
Comença gratis. Paga per ús. Escala a Enterprise.
Gratuït
0 $ / mes. No es requereix targeta de crèdit.
- Paquet KYC gratuït (Verificació d'identitat + Prova de vida passiva + Coincidència facial + Anàlisi de dispositius i IP) — 500 / mes, cada mes
- Usuaris bloquejats
- Detecció de duplicats
- Més de 200 senyals de frau en cada sessió
- KYC reutilitzable a tota la xarxa Didit
- Plataforma de gestió de casos
- Constructor de fluxos de treball
- Documents públics, sandbox, SDK, servidor MCP (Model Context Protocol)
- Suport de la comunitat
Basat en l'ús
Paga només pel que utilitzes. Més de 25 mòduls. Preus públics per mòdul, sense quota mínima mensual.
- KYC complet per 0,33 $ (ID + Biomètric + IP / Dispositiu)
- Més de 10.000 conjunts de dades AML — sancions, PEPs, mitjans adversos
- Més de 1.000 fonts de dades governamentals per a la validació de bases de dades
- Monitorització de transaccions per 0,02 $ per transacció
- KYB en viu per 2,00 $ per negoci
- Cribratge de carteres per 0,15 $ per comprovació
- Flux de verificació de marca blanca — la teva marca, la nostra infraestructura
Empreses
MSA i SLA personalitzats. Per a grans volums i programes regulats.
- Contractes anuals
- MSA, DPA i SLA personalitzats
- Canal dedicat de Slack i WhatsApp
- Revisors manuals a demanda
- Condicions de revenda i marca blanca
- Funcions exclusives i integracions amb socis
- CSM assignat, revisió de seguretat, suport de compliment
Comença gratis → paga només quan s'executa una comprovació → desbloqueja Enterprise per a un contracte personalitzat, SLA o residència de dades.
Preguntes de desenvolupadors, respostes.
Com integro Didit?
Cinc passos des del registre fins al primer veredicte.
- Creeu el vostre compte a
business.didit.me, o truqueu aPOST https://apx.didit.me/auth/v2/programmatic/register/. - Creeu un flux de treball a la Business Console, o truqueu a
POST /v3/workflows/. - Registreu una destinació de webhook mitjançant la consola, o truqueu a
POST /v3/webhook/destinations/(Didit retorna el secret de signatura a la resposta). - Creeu una sessió amb
POST /v3/session/, passantworkflow_idivendor_data(el vostre identificador d'usuari). Redirigiu l'usuari a l'URL retornada — o incorporeu un Software Development Kit (SDK) natiu al mateix contracte/v3/. - Rebeu el veredicte al webhook signat, o consulteu
GET /v3/session/:session_id/decision/.
Una Application Programming Interface (API) /v3/ cobreix Know Your Customer (KYC), Know Your Business (KYB), Transaction Monitoring i Wallet Screening (KYT — coneix la teva transacció). 500 verificacions gratuïtes cada mes, per sempre, sense targeta de crèdit.
Hi ha un sandbox amb el qual pugui jugar ara mateix?
Sí — en menys de seixanta segons, sense targeta de crèdit. Registreu-vos a business.didit.me (o registreu-vos programàticament amb POST https://apx.didit.me/auth/v2/programmatic/register/) i aterrareu en un espai de treball de sandbox amb una clau d'Application Programming Interface (API) real.
- La mateixa forma que la producció — decisions deterministes, tots els mòduls desbloquejats.
- Punts finals
/v3/reals, webhooks reals, exemples de documents reals. - Canvieu a la versió en viu quan estigueu preparats — les mateixes claus, les mateixes Uniform Resource Locators (URLs), el mateix contracte.
Quins Software Development Kits (SDKs) proporcioneu?
Cinc SDKs de primera part, tots de codi obert, tots a la documentació pública:
- Web — JavaScript / TypeScript, agnòstic del framework, incrustació d'iframe o redirecció de flux allotjat.
- iOS — Swift, distribuït com a
XCFramework. - Android — Kotlin, mitjançant Maven Central.
- React Native — enllaços TypeScript sobre mòduls natius (TurboModules).
- Flutter — embolcall Dart al voltant dels mateixos SDKs natius.
Cada SDK crida el mateix contracte /v3/ internament, de manera que podeu barrejar i combinar — Web al vostre lloc, natiu al mòbil. Referència a docs.didit.me/integration/web-sdks/overview.
Com funcionen els webhooks?
Registreu una destinació; Didit signa cada lliurament.
- Configureu el vostre punt final mitjançant la Business Console — o truqueu a
POST /v3/webhook/destinations/amblabel,urlisubscribed_events. - Didit retorna una
secret_shared_keya la resposta. Utilitzeu-la per verificar la signatura Hash-based Message Authentication Code (HMAC)-SHA256 a cada webhook entrant (capçalera:X-Signature-V2). - Cada càrrega útil conté un
statusexacte, sensible a majúscules i minúscules —"Approved","Declined","In Review","Resubmitted", i més. Màquina d'estats completa adocs.didit.me/integration/verification-statuses. - Els reintents utilitzen retrocessos exponencials fins que retorneu
2xx; cada lliurament es registra i és reproduïble sota demanda des de la consola.
Referència completa a docs.didit.me/integration/webhooks.
Quins són els límits de velocitat i què passa a escala?
Valors predeterminats generosos en cada pla, ajustats a l'alça per compte.
- Nivell gratuït — sandbox més 500 comprovacions de producció cada mes, per sempre.
- Pagament per ús — els límits de ràfega s'escalen automàticament amb el volum sostingut. No toparàs amb un mur a mig llançament.
- Enterprise — límits de velocitat personalitzats, capacitat dedicada i compromisos de temps d'activitat en l'Acord de Serveis Mestre (MSA). Parla amb nosaltres a
support@didit.me.
Capacitat objectiu per regió a status.didit.me. 100% de temps d'activitat real durant els últims 6 mesos a través de milions de verificacions al mes.
Puc integrar-me amb Claude Code, Cursor o altres eines de codificació d'IA?
Sí — enganxa una indicació i envia. Deixa caure la indicació d'integració canònica a docs.didit.me/integration/integration-prompt a Claude Code, Cursor, Codex, Devin, Aider o Replit Agent. L'agent proveeix el flux de treball, connecta el webhook i executa una prova de fum de principi a fi.
Les sessions iniciades per l'agent paguen el mateix preu públic que les trucades directes a l'API — $0.33 per cada Know Your Customer (KYC) complet, $0.15 per cada verificació de document d'identitat autònoma, $0.15 per cada revisió de cartera. Gratuït, sense configuració addicional, funciona amb qualsevol client compatible amb el Model Context Protocol (MCP).
On és el registre de canvis i com versionen l'API?
Notes de llançament mensuals a `docs.didit.me/changelog` — cada mòdul enviat, cada esdeveniment de webhook afegit, cada canvi disruptiu assenyalat.
- L'especificació OpenAPI 3.1 a
docs.didit.me/openapi-25.jsones versiona juntament amb la documentació. Importa-la a Postman o genera clients en qualsevol idioma. - El versionat és additiu per defecte. Els nous camps, els nous paràmetres opcionals i els nous esdeveniments de webhook s'envien sense un augment de versió. Els canvis disruptius obtenen un nou espai de noms
/v4/i una finestra de deprecació publicada. - Mai canviem silenciosament el significat d'un camp — si la forma d'un veredicte, l'esquema de signatura o l'enumeració d'estat canvien, s'envia darrere d'una capçalera i s'anuncia abans del canvi.
Com monitoritzo el temps d'activitat i quin és el procés d'incidències?
`status.didit.me` publica el temps d'activitat en temps real i l'historial d'incidències per regió — verificació, webhooks, consola, documentació. No cal iniciar sessió.
- Subscriu-te mitjançant Really Simple Syndication (RSS), correu electrònic o webhook per a alertes d'interrupció.
- Historial: 100% de temps d'activitat real durant els últims 6 mesos; objectiu de disponibilitat del 99,99% en l'Acord de Nivell de Servei (SLA).
- Cada incident rep un post-mortem públic a la mateixa pàgina.
- Els contractes Enterprise afegeixen un enginyer de guàrdia assignat, un canal compartit dedicat a Slack o Microsoft Teams, i Objectius de Nivell de Servei de gravetat d'incidències en l'Acord de Serveis Mestre (MSA).
Infraestructura per a la identitat i el frau.
Una API per a KYC, KYB, monitorització de transaccions i anàlisi de carteres. Integra-ho en 5 minuts.