Encuentre cada módulo, endpoint y webhook.
La mejor manera de integrar
identidad y fraude.
Abra el entorno de pruebas, pegue un curl y envíe en 5 minutos. Documentación pública, cinco kits de desarrollo de software (SDK) y un servidor de Protocolo de Contexto de Modelo (MCP) para que un agente de codificación de Inteligencia Artificial (IA) pueda integrar Didit por usted. $0.33 por verificación KYC completa, 500 gratis cada mes.




Con la confianza de más de 2.000 organizaciones en todo el mundo.
De cero a verificado en cinco minutos.
Cree su cuenta Didit.
- En la Consola de Negocios: regístrese en
business.didit.meen menos de sesenta segundos — sin tarjeta, sin barreras de venta. - Por Interfaz de Programación de Aplicaciones (API): llame a
POST https://apx.didit.me/auth/v2/programmatic/register/, luegoPOST .../verify-email/.
Cualquiera de las rutas le deja con una clave API de entorno de pruebas — con la misma forma que la de producción, con todos los módulos desbloqueados.
Emitido justo ahora — sin tarjeta, sin contrato, sin llamada.
- Sin mínimo
- Sin contrato
- 500 gratis / mes
- Sandbox abierto
Elija los módulos. Componga el flujo de trabajo.
- En la Consola de Negocios: arrastre y suelte los módulos en el Constructor de Flujos de Trabajo — Verificación de Documentos de Identidad, Prueba de Vida Pasiva, Coincidencia Facial, Antilavado de Dinero (AML), Detección de Billeteras, Análisis de Protocolo de Internet (IP) y 19 más.
- Por API: llame a
POST /v3/workflows/enverification.didit.mecon los módulos que desee.
Cualquiera de las rutas devuelve un workflow_id que pasará en cada sesión.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Prueba de Domicilio
- Lectura NFC
- Verificación Telefónica
- Detección de Monederos
- Cuestionario Personalizado
Configure un destino de webhook para cada veredicto.
- En la Consola de Negocios: añada su Localizador Uniforme de Recursos (URL) del webhook, elija los eventos y copie el secreto de firma que Didit genera.
- Por API: llame a
POST /v3/webhook/destinations/conlabel,urlysubscribed_events. La respuesta devuelve lasecret_shared_keyque Didit utiliza para firmar cada entrega.
- 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 endpoint abierto · cada webhook firmado con HMAC.
Cree una sesión — Kit de desarrollo de software (SDK) o API directa.
- Con un Kit de Desarrollo de Software (SDK): incorpore el SDK nativo para Web, iOS, Android, React Native o Flutter — el mismo contrato
/v3/subyacente. - Por API: llame a
POST /v3/session/con elworkflow_idy un valorvendor_data(su identificador de usuario).
La respuesta le proporciona una URL de verificación para redirigir o incrustar en su aplicación.
$ 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"
}'Escuche en el webhook — o sondee.
- Webhook en tiempo real: su endpoint se activa con cada cambio de estado. Lea el
status("Approved","Declined","In Review","Resubmitted", …), actualice su base de datos, envíe. - Mediante sondeo: llame a
GET /v3/session/:session_id/decision/para la misma carga útil, útil cuando su pila no puede aceptar tráfico entrante.
Las cadenas de estado son exactas y distinguen entre mayúsculas y minúsculas. Máquina de estado completa en 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
Cada superficie, pública. Cero llamadas de ventas.
Envíe un flujo KYC en 5 minutos.
Lea la especificación OpenAPI 3.1.
Incruste en Web, iOS, Android, React Native o Flutter.
Reciba eventos firmados con HMAC en cada cambio de estado.
Lea la máquina de estados de sesión completa.
Pegue una instrucción. Envíe la integración KYC.
Conecte Didit a cualquier cliente MCP.
Habilidades de verificación, AML y KYB preconstruidas.
Un curl. Cinco 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"
}'Construido para desarrolladores y agentes de IA.
Una API para identidad y 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",
"callback": "https://acme.com/webhook"
}'Integrar en una sola instrucción.
# 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.
Cualquier flujo. Cualquier país. Cualquier caso de uso.
- ID Verification
- Passive Liveness
- Face Match 1:1
- AML Screening
- Device & IP Analysis
- Prueba de Domicilio
- Lectura NFC
- Verificación Telefónica
- Detección de Monederos
- Cuestionario Personalizado
Sin muro de pago. Sin llamada de ventas. Vaya a jugar con él.
Emitido justo ahora — sin tarjeta, sin contrato, sin llamada.
- Sin mínimo
- Sin contrato
- 500 gratis / mes
- Sandbox abierto
Pague por lo que usa. Eso es todo.
- ID Verification$0.15
- Passive Liveness$0.10
- Face Match 1:1$0.05
- AML Screening$0.20
- Device & IP Analysis$0.03
- Detección de Monederos (KYT)$0.15
500 gratis / mes · sin mínimo · sin contrato anual.
API abierta. Construya sobre ella.
- 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 endpoint abierto · cada webhook firmado con HMAC.
SDKs para cada plataforma.
Las verificaciones más rápidas del mercado.
- p500.82s
- p951.42s
- p991.89s
Verificaciones más rápidas del mercado · iPhone, Android, escritorio, tableta, 5G o 2G.
Empiece gratis. Pague por uso. Escale a Enterprise.
Gratis
$0 / mes. No se requiere tarjeta de crédito.
- Paquete KYC gratuito (Verificación de ID + Prueba de vida pasiva + Coincidencia facial + Análisis de dispositivo e IP) — 500 / mes, cada mes
- Usuarios en lista negra
- Detección de duplicados
- Más de 200 señales de fraude en cada sesión
- KYC reutilizable en la red Didit
- Plataforma de gestión de casos
- Constructor de flujos de trabajo
- Documentos públicos, sandbox, SDKs, servidor MCP (Model Context Protocol)
- Soporte comunitario
Basado en el uso
Pague solo por lo que usa. Más de 25 módulos. Precios públicos por módulo, sin tarifa mínima mensual.
- KYC completo por $0.33 (ID + Biométrico + IP / Dispositivo)
- Más de 10,000 conjuntos de datos AML — sanciones, PEPs, medios adversos
- Más de 1,000 fuentes de datos gubernamentales para la Validación de Bases de Datos
- Monitoreo de Transacciones por $0.02 por transacción
- KYB en vivo por $2.00 por negocio
- Análisis de Billetera por $0.15 por verificación
- Flujo de verificación de marca blanca — su marca, nuestra infraestructura
Empresarial
MSA y SLA personalizados. Para grandes volúmenes y programas regulados.
- Contratos anuales
- MSA, DPA y SLA personalizados
- Canal dedicado de Slack y WhatsApp
- Revisores manuales bajo demanda
- Términos de revendedor y marca blanca
- Funciones exclusivas e integraciones con socios
- CSM asignado, revisión de seguridad, soporte de cumplimiento
Empiece gratis → pague solo cuando se ejecute una verificación → desbloquee Enterprise para un contrato personalizado, SLA o residencia de datos.
Preguntas de desarrolladores, respondidas.
¿Cómo integro Didit?
Cinco pasos desde el registro hasta el primer veredicto.
- Cree su cuenta en
business.didit.me, o llame aPOST https://apx.didit.me/auth/v2/programmatic/register/. - Cree un flujo de trabajo en la Consola de Negocios, o llame a
POST /v3/workflows/. - Registre un destino de webhook a través de la consola, o llame a
POST /v3/webhook/destinations/(Didit devuelve el secreto de firma en la respuesta). - Cree una sesión con
POST /v3/session/, pasandoworkflow_idyvendor_data(su identificador de usuario). Redirija al usuario a la URL devuelta — o inserte un Software Development Kit (SDK) nativo en el mismo contrato/v3/. - Reciba el veredicto en el webhook firmado, o consulte
GET /v3/session/:session_id/decision/.
Una Application Programming Interface (API) /v3/ cubre Know Your Customer (KYC), Know Your Business (KYB), Monitoreo de Transacciones y Cribado de Billeteras (KYT — conozca su transacción). 500 verificaciones gratuitas cada mes, para siempre, sin tarjeta de crédito.
¿Hay un sandbox con el que pueda jugar ahora mismo?
Sí, en menos de sesenta segundos, sin tarjeta de crédito. Regístrese en business.didit.me (o regístrese programáticamente con POST https://apx.didit.me/auth/v2/programmatic/register/) y accederá a un espacio de trabajo sandbox con una clave de Application Programming Interface (API) real.
- Misma forma que la producción: decisiones deterministas, todos los módulos desbloqueados.
- Puntos finales
/v3/reales, webhooks reales, ejemplos de documentos reales. - Cambie a producción cuando esté listo: mismas claves, mismas Uniform Resource Locators (URLs), mismo contrato.
¿Qué Software Development Kits (SDKs) distribuyen?
Cinco SDKs de primera parte, todos de código abierto, todos en la documentación pública:
- Web — JavaScript / TypeScript, agnóstico de framework, incrustación de iframe o redirección de flujo alojado.
- iOS — Swift, distribuido como
XCFramework. - Android — Kotlin, a través de Maven Central.
- React Native — enlaces TypeScript sobre módulos nativos (TurboModules).
- Flutter — envoltorio Dart alrededor de los mismos SDKs nativos.
Cada SDK llama al mismo contrato /v3/ internamente, por lo que puede mezclarlos y combinarlos — Web en su sitio, nativo en móvil. Referencia en docs.didit.me/integration/web-sdks/overview.
¿Cómo funcionan los webhooks?
Registre un destino; Didit firma cada entrega.
- Configure su endpoint a través de la Consola de Negocios — o llame a
POST /v3/webhook/destinations/conlabel,urlysubscribed_events. - Didit devuelve una
secret_shared_keyen la respuesta. Úsela para verificar la firma Hash-based Message Authentication Code (HMAC)-SHA256 en cada webhook entrante (encabezado:X-Signature-V2). - Cada carga útil lleva un
statusexacto y sensible a mayúsculas y minúsculas —"Approved","Declined","In Review","Resubmitted", y más. Máquina de estados completa endocs.didit.me/integration/verification-statuses. - Los reintentos utilizan retroceso exponencial hasta que devuelva
2xx; cada entrega se registra y es reproducible bajo demanda desde la consola.
Referencia completa en docs.didit.me/integration/webhooks.
¿Cuáles son los límites de velocidad y qué sucede a escala?
Valores predeterminados generosos en cada plan, ajustados al alza por cuenta.
- Nivel gratuito — sandbox más 500 verificaciones de producción cada mes, para siempre.
- Pago por uso — los límites de ráfaga se escalan automáticamente con el volumen sostenido. No te encontrarás con un muro a mitad del lanzamiento.
- Empresarial — límites de velocidad personalizados, capacidad dedicada y compromisos de tiempo de actividad en el Acuerdo Maestro de Servicios (MSA). Habla con nosotros en
support@didit.me.
Capacidad objetivo por región en status.didit.me. 100% de tiempo de actividad real en los últimos 6 meses en millones de verificaciones al mes.
¿Puedo integrar con Claude Code, Cursor u otras herramientas de codificación de IA?
Sí — pega una instrucción y envía. Introduce la instrucción de integración canónica en docs.didit.me/integration/integration-prompt en Claude Code, Cursor, Codex, Devin, Aider o Replit Agent. El agente aprovisiona el flujo de trabajo, conecta el webhook y ejecuta una prueba de humo de extremo a extremo.
Las sesiones iniciadas por el agente pagan el mismo precio público que las llamadas directas a la API — $0.33 por una verificación completa de Know Your Customer (KYC), $0.15 por una verificación de documento de identidad independiente, $0.15 por una revisión de billetera. Gratis, sin configuración adicional, funciona con cualquier cliente compatible con el Protocolo de Contexto de Modelo (MCP).
¿Dónde está el registro de cambios y cómo versionan la API?
Notas de lanzamiento mensuales en `docs.didit.me/changelog` — cada módulo enviado, cada evento de webhook añadido, cada cambio importante señalado.
- La especificación OpenAPI 3.1 en
docs.didit.me/openapi-25.jsonse versiona junto con la documentación. Impórtala en Postman o genera clientes en cualquier idioma. - El versionado es aditivo por defecto. Los nuevos campos, los nuevos parámetros opcionales y los nuevos eventos de webhook se envían sin un aumento de versión. Los cambios importantes obtienen un nuevo espacio de nombres
/v4/y una ventana de deprecación publicada. - Nunca cambiamos silenciosamente el significado de un campo — si la forma de un veredicto, el esquema de firma o el enumerador de estado cambian, se envía detrás de un encabezado y se anuncia antes del cambio.
¿Cómo monitoreo el tiempo de actividad y cuál es el proceso de incidentes?
`status.didit.me` publica el tiempo de actividad en tiempo real y el historial de incidentes por región — verificación, webhooks, consola, documentos. No se requiere inicio de sesión.
- Suscríbete a través de Really Simple Syndication (RSS), correo electrónico o webhook para recibir alertas de interrupción.
- Historial: 100% de tiempo de actividad real en los últimos 6 meses; objetivo de disponibilidad del 99.99% en el Acuerdo de Nivel de Servicio (SLA).
- Cada incidente recibe un informe post-mortem público en la misma página.
- Los contratos empresariales añaden un ingeniero de guardia asignado, un canal compartido dedicado en Slack o Microsoft Teams, y Objetivos de Nivel de Servicio de gravedad de incidentes en el Acuerdo Maestro de Servicios (MSA).
Infraestructura para la identidad y el fraude.
Una API para KYC, KYB, monitoreo de transacciones y detección de billeteras. Intégrelo en 5 minutos.