Saltar al contingut principal
Esta guia us explica el flux complet per integrar la verificació d’identitat de Didit mitjançant l’API REST: obtenir les credencials, crear una sessió, presentar-la a l’usuari i rebre els resultats.

Pas 1: obtén les teves credencials

Hi ha dues maneres d’obtenir una api_key:

Opció A: registre programàtic (sense navegador)

Ideal per a CI/CD i agents d’IA. Són dues crides a l’API: POST /programmatic/register/ i després POST /programmatic/verify-email/, que retornen la api_key en línia. → Consulta Registre programàtic per al flux complet, les regles de contrasenya, la durada del JWT i la política de bloqueig.

Opció B: des de la Didit Console

  1. Ves a la Didit Console.
  2. Crea o selecciona la teva organització.
  3. Navega a Configuració → API i Webhooks.
  4. Copia:
    • Clau d’API: s’utilitza com a capçalera x-api-key en cada crida de verificació.
    • Clau secreta del webhook: s’utilitza per verificar les signatures HMAC dels webhooks.

Variables d’entorn


Pas 2: crea un flux de treball

Abans de crear sessions, necessites un flux de treball de verificació. Els fluxos de treball defineixen els passos de verificació pels quals passen els usuaris.

Crea’l a la Console

  1. Ves a la Didit Console → Fluxos de treball
  2. Fes clic a Crear flux de treball
  3. Tria una plantilla base:
  1. Afegeix funcionalitats opcionals:
  1. Copia el ID del flux de treball
Consulta la documentació dels fluxos de treball per a les opcions de configuració detallades.

Pas 3: Crea una sessió de verificació

Crida l’API per crear una sessió per a l’usuari.

Sol·licitud

Paràmetres de la sol·licitud

Exemple complet amb totes les opcions

expected_details.expected_document_types restringeix el pas de verificació d’identitat a tipus de document concrets: la pantalla de selecció de documents només mostra els tipus sol·licitats. Valors permesos: P (passaport), ID (document nacional d’identitat), DL (permís de conducció), RP (permís de residència), HIC (targeta d’assegurança de salut), TC (targeta fiscal) i SSC (targeta de la seguretat social). Els valors no distingeixen majúscules i minúscules i es deduplican; els valors desconeguts retornen 400. Consulta la referència de creació de la sessió per veure l’esquema complet.

Resposta

201 Created:

Camps clau de la resposta

Idempotència. Quan es proporciona vendor_data i ja existeix a la versió publicada més recent del flux de treball una sessió no finalitzada (Not Started, In Progress, Resubmitted o Awaiting User) amb el mateix vendor_data, es retorna aquesta sessió existent (encara amb 201) en lloc de crear-ne un duplicat. El seu callback i metadata s’actualitzen amb els nous valors, i status reflecteix l’estat de la sessió existent.
Si falta x-api-key, es retorna 403 amb {"detail": "You do not have permission to perform this action."}, el mateix cos que una clau vàlida sense permís. Una clau incorrecta, revocada o caducada retorna 401. Els crèdits insuficients retornen 400. Consulta Referència de l’API de creació de la sessió per a la documentació completa.

Pas 4: Presenta la verificació a l’usuari

Tria com presentar el flux de verificació a l’usuari:

Opció A: SDK natiu (recomanat per a mòbil)

Fes servir el session_token amb els SDK natius per a la integració de la càmera, NFC i biometria. → iOS SDK · Android SDK · React Native · Flutter

Opció B: iframe InContext (recomanat per a web)

Incrusta la verificació a la teva pàgina utilitzant la url retornada al pas 3.
→ iframe InContext

Opció C: Redirecció

Redirigeix l’usuari a la URL de verificació.
→ Redirecció web

Opció D: WebView mòbil

Per a aplicacions mòbils sense SDK natiu.
→ WebView a iOS/Android

Pas 5: Rebre els resultats

Mitjançant webhook (recomanat)

Els webhooks notifiquen el vostre servidor en temps real cada vegada que canvia l’estat de la verificació. Configuració:
  1. Creeu una destinació de webhook a la Consola (API i Webhooks) o mitjançant POST /v3/webhook/destinations/ amb webhook_version: "v3" i un array subscribed_events (p. ex., ["status.updated"])
  2. Deseu el secret_shared_key que es retorna en crear-la: és el secret HMAC per a totes les variants de signatura
  3. Implementeu un endpoint de webhook al vostre servidor
Exemple de payload de webhook: Dins de decision, cada resultat per funcionalitat s’entrega com a array en plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …): una entrada per cada node del flux de treball. Aquest és el contracte de la V3 i és inamovible: mai no programeu contra les claus en singular nfc / id_verification / liveness.
L’objecte decision només està present quan status és Approved, Declined, In Review o Abandoned (un esdeveniment Resubmitted porta resubmit_info en lloc d’això). Didit reutilitza el mateix event_id en els reintents i les destinacions de distribució múltiple: utilitzeu-lo com a clau d’idempotència. Consulteu Models de dades per a tots els arrays en plural i camps. Verifiqueu la signatura (X-Signature-V2, recomanada): X-Signature-V2 és HMAC-SHA256 sobre una recodificació canònica del cos JSON: els floats amb valor enter es redueixen a enters, les claus s’ordenen de manera recursiva, els separadors són compactes i Unicode es preserva.
→ Documentació completa dels webhooks, inclosa la X-Signature sobre bytes bruts, la X-Signature-Simple obsoleta (només sobre l’envoltori) i com triar-ne una. Didit reintenta els lliuraments fallits (5xx, 404, temps d’espera) fins a 2 vegades (~1 min, després ~4 min) i el temps d’espera és de 5 segons: retorneu 2xx ràpidament.

Mitjançant API (opcional)

Obteniu el mateix payload de decisió en qualsevol moment:
La forma de la resposta (arrays en plural) és idèntica a l’objecte decision dins del payload del webhook, i l’endpoint es pot cridar en qualsevol punt del cicle de vida de la sessió. Utilitzeu els webhooks per a les actualitzacions en temps real i reserveu les crides a l’API per a la recuperació de dades, l’auditoria i les reconstruccions: l’endpoint /decision/ té un límit de 600 sol·licituds GET per minut per clau d’API (consulteu Límit de freqüència). Semàntica d’errors: un session_id desconegut retorna 404 amb {"detail": "Not found."}; els errors d’autenticació apareixen com a 403; aquest endpoint mai no retorna 401. Les URL de mitjans de la resposta són enllaços prefirmats de vida curta: obteniu-les de seguida en lloc de persistir-les. → Referència de l’API per recuperar la sessió

Exemples de codi complets

Node.js / Express

Python / FastAPI


Estats de la sessió

Aquests són els 10 valors possibles de status: cadenes exactes i sensibles a majúscules (fixeu-vos que Kyc Expired té una sola K majúscula): Consulteu Estats de verificació per al cicle de vida complet, les transicions i el diagrama de Mermaid.

Següents passos

  1. Trieu el vostre mètode d’integració:
  2. Configureu els webhooks: Webhooks
  3. Planifiqueu la capacitat: Límit de freqüència
  4. Gestioneu tots els estats: Estats de verificació
  5. Personalitzeu el vostre flux de treball: Fluxos de treball
  6. Verifiqueu que l’API és accessible: Comprovació de l’estat

Necessites ajuda?

Darrera modificació el 7 de novembre del 2026