Saltar al contingut principal
La funcionalitat de Validació en bases de dades de Didit confronta les dades d’identitat de cada usuari amb la font autoritzada de referència d’aquell país — RENAPER (Argentina), Receita Federal (Brasil), Tribunal Electoral (Panamà, amb coincidència facial biomètrica), Junta Central Electoral (República Dominicana) i més —, facturada per consulta satisfactòria sense mínims mensuals. Cada entrada de database_validations[] és un informe complet de Validació en bases de dades — una execució d’un node de Validació en bases de dades contra un estat emissor. Els resultats del registre per servei es troben dins de l’array validations[] d’aquesta entrada. Aquesta pàgina documenta l’estructura JSON perquè puguis analitzar els resultats de coincidència, les dades d’origen del registre i les puntuacions biomètriques retornades per cada servei.
Informe de validació en bases de dades de Didit que mostra els tipus de coincidència i els camps de resposta del registre

Visió general

Es genera un informe de Validació en bases de dades cada vegada que un node del flux de treball executa la funcionalitat de Validació en bases de dades. Cada entrada del vector database_validations[] representa l’execució d’un node contra un estat emissor; si el node executa diversos serveis per a aquest país (per exemple CPF + CNH al Brasil), cada servei apareix com un element separat dins de l’array validations[] de l’entrada. Cada informe conté:
  • L’status global de la funcionalitat — un valor de FeatureStatusChoices (Not Finished, Approved, Declined, In Review).
  • Un match_type agregat (full_match, partial_match, no_match, o null quan cap servei ha retornat un resultat utilitzable) consolidat entre serveis mitjançant el mètode de coincidència.
  • L’issuing_state (ISO 3166-1 alfa-3) i el validation_type derivat (one_by_one, two_by_two, o not_enabled — mai null).
  • El bloc screened_data — les dades proporcionades per l’usuari que s’han enviat al registre.
  • Un vector validations[] — una entrada per servei que hagi generat un resultat, amb el service_id/service_name del catàleg, l’outcome_code independent del proveïdor, un outcome_detail opcional, el mapa validation per camp i el source_data net extret de la resposta del registre.
  • Un vector errors[] — errors per servei quan una consulta ha fallat o s’ha omès; la clau s’omet completament quan no hi ha errors.
  • Un vector warnings[] — esdeveniments de risc emesos durant la validació (consulta Advertències de Validació en bases de dades).
  • Un node_id que identifica quin node del graf del flux de treball ha generat l’informe (només per a sessions V3).

On apareix a les respostes de l’API

L’informe apareix com a database_validations[] a GET /v3/session/{sessionId}/decision/ — sempre com a array JSON, mai com a objecte singular. El vector conté una entrada per node de Validació en bases de dades al graf del flux de treball; al seu torn, l’array validations[] de cada entrada conté un element per servei de registre que hagi generat un resultat.
Un valor null significa que encara no s’ha executat cap pas de Validació en bases de dades.

Schema

L’esquema canònic camp per camp es troba a la pàgina Models de dades. El genera DatabaseValidationV3Serializer.

Valors d’estat

status utilitza l’enum estàndard a nivell de funcionalitat (consulta Enums d’estat) — consulta la Referència d’enums d’estat. L’enum també defineix Resub Requested, que a la pràctica no el genera Validació en bases de dades. S’apliquen regles d’estat personalitzades per node a sobre d’aquest estat base. Consulta Advertències de Validació en bases de dades per a les accions configurables i els seus valors per defecte.

Codis de resultat

Cada entrada de validations[] inclou un outcome_code neutral respecte al proveïdor — un d’entre MATCH, PARTIAL_MATCH, NO_MATCH, DOCUMENT_NOT_FOUND, INVALID_DOCUMENT_FORMAT, INVALID_INPUT, MINOR_BLOCKED, DECEASED, BIOMETRIC_NO_MATCH, BIOMETRIC_IMAGE_UNUSABLE, INCONCLUSIVE, DOCUMENT_SUPERSEDED, REGISTRY_UNAVAILABLE, REGISTRY_ERROR. Tingues en compte les distincions: NO_MATCH significa que el registre no ha confirmat les dades de manera definitiva, INCONCLUSIVE significa que el registre no ha pogut determinar ni una cosa ni l’altra (deriva a revisió, no a rebuig), i BIOMETRIC_IMAGE_UNUSABLE és un problema tècnic de la selfie (cal tornar-la a fer) — a diferència del definitiu BIOMETRIC_NO_MATCH. Consulta la taxonomia completa i la gestió recomanada a la pàgina Codis de resultat.

Una entrada per servei

La llista validations[] conté un element per a cada servei que hagi generat un payload de resultats (un mapa de validation, source_data, outcome_code o outcome_detail). Si el teu flux de treball executa diversos serveis per al mateix país (per exemple, CPF del Brasil + CNH del Brasil), cadascun apareix per separat amb el seu propi service_id, outcome_code i source_data. El match_type consolidat agrega els resultats de tots els serveis (qualsevol coincidència total → full_match; si no, qualsevol parcial → partial_match; si no, no_match), i validation_type es deriva de quants serveis diferents han tingut una coincidència total — consulta Mètodes de coincidència.

URL d’imatges signades prèviament

Els camps d’imatge a source_data (photo, signature) i screened_data (selfie, cnh_qr_code_image, document_image) es retornen com a URL signades prèviament que caduquen — actualitza-les tornant a cridar l’endpoint de decisió. El payload en brut del proveïdor no s’exposa intencionadament a través de l’API.

Exemples

Aprovada — comprovació d’estat del CPF del Brasil (Receita Federal)

Aprovada — biometria del DNI de l’Argentina (RENAPER)

Per a l’Argentina, la validació utilitza RENAPER amb coincidència facial biomètrica. La resposta inclou un face_match_score i camps d’identitat addicionals retornats pel registre.

En revisió — el registre no s’ha pogut executar

Quan cap servei no retorna un resultat utilitzable — camps obligatoris absents o amb format incorrecte, o el registre no està disponible —, match_type es manté com a null, validation_type és not_enabled, s’emet una advertència COULD_NOT_PERFORM_DATABASE_VALIDATION i la funcionalitat passa a In Review fins que es corregeixin les dades. No s’aplica cap càrrec als serveis omesos.
Omple el camp que falta des de la pàgina de detall de la sessió a la Console — desar-lo torna a activar la comprovació automàticament i elimina l’advertència si és satisfactori.

Relacionat

Darrera modificació el 7 de novembre del 2026