> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Validación de base de datos: KYC con registros oficiales

> Didit valida la identidad en registros oficiales de 60+ países desde $0.05 por consulta, con coincidencia facial biométrica si el registro guarda la foto.

La **validación de base de datos** de Didit verifica los datos de identidad de una persona con la fuente autorizada de cada país: el registro civil nacional, la autoridad tributaria, el padrón electoral, el buró de crédito o el registro biométrico que emitió el documento en primer lugar. Cada comprobación devuelve una coincidencia por campo (`identification_number`, `first_name`, `last_name`, `date_of_birth` y campos de dirección cuando el servicio los usa), un resultado agregado y los detalles del registro subyacente cuando están disponibles.Es la mejor defensa contra el fraude de identidad sintética: un DNI o CPF real robado no superará la consulta al registro, y un número inventado no figurará en la base de datos oficial. La validación de base de datos se combina con nuestra coincidencia facial biométrica en los países donde el registro guarda una foto oficial (Argentina con RENAPER, Panamá con Tribunal Electoral SIB / SIB Plus), de modo que puedes confirmar no solo que un número es real, sino que la **persona que está frente a la cámara es su titular**.

Prompt de integración de la validación de base de datos
        Copy prompt to clipboard



      
      

\<pre>

\````# Goal
Integrate Didit Database Validation (verify identity data against authoritative national registries) into your app. Pick ONE mode.

\# Mode A — Session-based
Use this when Database Validation runs as a step in a hosted Didit flow. Fields are auto-fed into the registry lookup from the steps in front of it — ID Verification, NFC, Liveness, Phone/Email Verification, Proof of Address, Document AI or a Questionnaire. An ID Verification step is not required.

1\. Add the DATABASE_VALIDATION feature to the workflow (Business Console or POST /v3/workflows/). Optionally pin specific services per country.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open session.url for the user (or mount the Web/Mobile SDK).
4\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

Decision surface: `database_validations[]` array on the decision payload.

\# Mode B — Standalone API (server-to-server)
Use when you already have the identity data and want a one-shot registry check.

POST https://verification.didit.me/v3/database-validation/
multipart/form-data — x-api-key: YOUR_API_KEY

curl example (Brazil CPF):
\```bash
curl -X POST 'https://verification.didit.me/v3/database-validation/' \
-H "x-api-key: $DIDIT_API_KEY" \
-F "issuing_state=BRA" \
-F "identification_number=00000000191" \
-F "first_name=Jane" \
-F "last_name=Doe" \
-F "date_of_birth=1990-01-15" \
-F "vendor_data=user-1234"
\```
Returns: { request_id, database_validation: { match_type: "full_match"|"partial_match"|"no_match", validation_type, services_used, match_score, validations: [{ service, status, matched_fields, record_details }], warnings: [...] } }.

\# Important behaviour
\- Use `identification_number` (universal field) — Didit maps it to CPF/RUT/CURP/DNI/etc. by issuing_state.
\- Omit `services` to run the country's default service only. Pass `services=["bra_cpf"]` (etc.) to choose which services run — list several to run more than one.
\- Argentina (`arg_renaper`) and Panama (`pan_sib`) take an extra `selfie` (JPG/PNG/WebP up to 2 MB) and `gender` for biometric face-match against the registry photo.
\- Services flagged `requires_consent=true` in the catalog require `consent=true` (HTTP 400 otherwise).
\- Billing is **per successful service hit** — multi-service requests can produce multiple usage events.

\# Status / match_type
status: "Approved" | "In Review" | "Declined" (per the partial-match / no-match actions configured on the workflow)
match_type: "full_match" | "partial_match" | "no_match"

\# Warnings (LogWarningChoices.DATABASE_VALIDATION)
warnings[] risk codes include:
DATABASE_VALIDATION_NO_MATCH, DATABASE_VALIDATION_PARTIAL_MATCH, COULD_NOT_PERFORM_DATABASE_VALIDATION (biometric outcomes surface via per-service outcome_code, e.g. BIOMETRIC_NO_MATCH).
Full catalogue: /core-technology/database-validation/database-validation-warnings.

\# Failure modes to handle
\- HTTP 400 — service id not eligible for issuing_state, missing required field, missing consent for PAYGO services.
\- HTTP 502 with validation_errors[] — every selected upstream service failed; request is **not billed** and a COULD_NOT_PERFORM_DATABASE_VALIDATION log is written. Retry later or fall back to OCR-only.
\- match_type="no_match" — record not in registry; treat as synthetic identity per policy.
\- match_type="partial_match" — some fields match, others don't (e.g. DOB matches, name doesn't); route to review.

\# See also
\- Canonical schema: /reference/data-models#database-validation
\- Per-feature report: /core-technology/database-validation/database-validation-report
\- Risk catalogue: /core-technology/database-validation/database-validation-warnings
\- Outcome codes: /core-technology/database-validation/database-validation-outcome-codes
\- Full integration playbook: /integration/integration-prompt````

\</pre>



      
      

Paste into

## Por qué Didit- **Los precios de pago por llamada más bajos.** Desde **\$0.05** por comprobación (República Dominicana) hasta **\$7.00** para las fuentes especializadas más caras. El precio se fija por servicio, no por país: un registro que cobra una tarifa mayorista alta se cotiza en consecuencia (el documento nacional de identidad de Finlandia cuesta **\$2.10**). Consulta siempre la tarifa del servicio exacto que vas a llamar en la [tabla de precios por servicio](https://docs.didit.me/getting-started/database-validation-pricing.md). Sin mínimos mensuales, sin comisiones de plataforma y sin facturación por usuario: solo se cobran las consultas correctas.
- **La integración más rápida.** [Regístrate](https://business.didit.me/), obtén una clave de API en la consola y podrás llamar a `POST /v3/database-validation/` en pocos minutos. Sin llamada comercial, sin proceso de compras y sin papeleo de prueba de concepto: Didit es totalmente de autoservicio.
- **Consultas directas a la fuente autorizada.** RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía: no son datos extraídos de agregadores.
- **Coincidencia facial biométrica cuando el registro tiene una foto oficial.** Mayor confianza que el OCR sin trabajo de integración adicional.
- **Latencia lista para producción.** El p95 suele ser inferior a 1.5 s de extremo a extremo y la disponibilidad trimestral es del 99.9%.La lección de la Academy sobre cómo leer un resultado de verificación llega a la validación de base de datos en el minuto 11:05 y muestra resultados de coincidencia total, parcial y nula.[Validación de base de datos: coincidencia total, parcial y nula — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Cobertura globalPasa el cursor por cualquier país resaltado para ver todos los servicios de validación de base de datos que ofrecemos allí, el dominio de datos (identidad, financiero, biométrico, dirección, telecomunicaciones, …) y el precio por llamada. Los países activos están listos para producción hoy; el resto se conectan bajo demanda cuando un cliente lo solicita.Live Database Validation coverageProduction-ready countries and the cheapest live service available in each.LIVE<details><summary>Show on-demand catalog countries ()</summary></details>> [!TIP]
>
> **¿No ves tu país?** Escríbenos: nuestro catálogo abarca 60+ países con cientos de servicios que activamos bajo demanda cuando un cliente los necesita. Las nuevas integraciones suelen estar activas en 2-3 semanas.## Cómo se ejecuta una validación de base de datosUna validación de base de datos nunca se lanza de forma especulativa. Solo se ejecuta cuando se cumplen **todas** estas condiciones:1) La sesión determinó un país que consultar: a partir del `issuing_state` de una [verificación de identidad](https://docs.didit.me/es/core-technology/id-verification/overview.md) o, cuando el flujo no tiene un paso de verificación de identidad, del único país para el que está configurado el paso de validación de base de datos.
2) Ese país tiene al menos un servicio de validación de base de datos habilitado en el flujo.
3) Los pasos anteriores al de validación de base de datos aportaron **todos los campos obligatorios** que necesita el servicio elegido.Si un servicio está habilitado pero los campos obligatorios nunca llegaron (por ejemplo, no se pudo extraer el CPF de un RG brasileño borroso), el servicio se omite, **no se te cobra** y se genera una advertencia en la sesión: `DATABASE_VALIDATION_NOT_APPLICABLE` cuando el documento simplemente no incluye el identificador por el que consulta ese servicio, y `COULD_NOT_PERFORM_DATABASE_VALIDATION` cuando debería haber estado disponible y no lo estaba. Ambas figuran en el [catálogo de advertencias](https://docs.didit.me/core-technology/database-validation/database-validation-warnings.md).Alguien de tu equipo con acceso de revisión a la sesión puede entonces completar el campo que falta a mano desde la página de detalle de la sesión en la Consola, y al guardarlo se vuelve a lanzar la comprobación automáticamente. Es una acción del revisor, no algo que pueda hacer el usuario final: para que el **usuario** aporte un campo que su documento no incluye, pídelo en un cuestionario (o en una extracción de Document AI, o como un valor que envíes al crear la sesión) y asígnalo en el paso de validación de base de datos, como se describe más abajo.### La validación de base de datos no requiere verificación de identidadAntes, un paso de validación de base de datos implicaba un paso de verificación de identidad anterior, porque el OCR de un documento de identidad era la única forma conectada de obtener los datos del usuario final. Ya no es así: **cada campo obligatorio declara qué pasos pueden aportarlo**, y un servicio queda disponible en cuanto tu flujo contiene un paso que aporte todos los campos que necesita.| Fuente de datos | Aporta |
| - | - |
| Verificación de identidad | Nombres, fecha de nacimiento, dirección, número de documento o personal y los identificadores propios de cada país impresos en un documento de identidad (número fiscal, documento nacional, número de pasaporte, número de licencia de conducir, …) |
| NFC | El subconjunto de lo anterior leído del chip, con mayor confianza |
| Prueba de vida | El selfie en vivo, para los servicios de registro con biometría facial |
| Verificación de teléfono | El número de teléfono verificado |
| Verificación de correo electrónico | La dirección de correo electrónico verificada |
| Prueba de domicilio | El domicilio residencial verificado y sus componentes |
| Document AI | Cualquier campo que asignes a una de tus claves de campo de extracción |
| Cuestionario | Cualquier campo que asignes a una de tus preguntas |
| Datos de la API | Cualquier dato, en la API independiente: quien llama aporta los valores directamente |Esto significa que un **servicio de biometría facial puede ejecutarse solo con un paso de prueba de vida**, sin ningún documento de identidad en el flujo, y que un servicio basado en un número fiscal, un teléfono o un correo electrónico puede satisfacerse con la respuesta de un cuestionario, un paso de verificación de teléfono o correo electrónico o una extracción de Document AI.Dos reglas lo mantienen seguro:- **Un flujo sin verificación de identidad debe configurar exactamente un país** en el paso de validación de base de datos. Sin un `issuing_state` procedente de un documento, esa es la única señal inequívoca de qué registro nacional consultar, así que una configuración multipaís sin verificación de identidad no ejecuta nada en lugar de adivinar.
- **La comprobación de campos obligatorios no cambia.** Un servicio cuyos campos no están todos presentes en el momento de la ejecución se omite antes de consultar a ningún proveedor, de modo que nunca se te factura una base de datos que no llegó a consultarse.#### Asignación de campos de Document AI y de cuestionariosLos campos de extracción de Document AI y las preguntas de los cuestionarios usan *tus* nombres de clave, no los de Didit. Una clave que coincide exactamente con el nombre de un dato de entrada de la validación de base de datos (`tax_number`, `date_of_birth`, `phone`, …) se asigna automáticamente y no requiere configuración. Para cualquier otra, el editor de flujos muestra un selector en el paso de validación de base de datos para los campos que siguen sin rellenar, donde indicas la clave de campo de Document AI o la respuesta del cuestionario que lo aporta.En la Consola, un servicio que tu flujo todavía no puede ejecutar aparece deshabilitado con el motivo (qué campos faltan y qué paso los aportaría), y el editor se ofrece a añadir ese paso por ti. Al añadirlo se activan de inmediato todos los servicios que desbloquea.> [!TIP]
>
> **Ejemplo práctico: un identificador que el documento no incluye.** El servicio de documento nacional de Nigeria consulta por el NIN de 11 dígitos, que con frecuencia no está impreso en los documentos que suben las personas, así que depender solo del documento de identidad deja la comprobación omitida por no aplicable para una gran parte de los usuarios. Pon un paso de **cuestionario** antes del paso de validación de base de datos que pida el NIN y luego asigna `national_id` a esa pregunta en el paso de validación de base de datos. Esa misma asignación es la que permite usar dentro de un flujo un identificador que nunca figura en ningún documento, como un número de verificación bancaria o un número de registro mercantil.Para los servicios basados en direcciones, Didit divide automáticamente el único `address` del documento de identidad en elementos de dirección estructurados:| Campo de Didit | Significado |
| - | - |
| `address_element_1` | Dirección postal, con número y tipo de vía |
| `address_element_2` | Unidad, edificio, piso o línea de dirección adicional (opcional) |
| `address_element_3` | Barrio, distrito, localidad o colonia |
| `address_element_4` | Ciudad, municipio, estado, provincia o región |
| `address_element_5` | Código postal |Al llamar a la API independiente, puedes enviar un único `address` o estos campos estructurados directamente. Los campos estructurados prevalecen cuando están presentes ambos. Los servicios que requieren búsqueda de direcciones necesitan `address_element_1` más al menos otro elemento de dirección; si Didit no puede obtenerlos del documento de identidad o de la prueba de domicilio del flujo, el servicio se omite y no se factura.Si el país determinado no está habilitado en absoluto, el paso se omite en silencio, sin advertencia y sin cargo.![Flujo de validación de base de datos de Didit que comprueba los datos del usuario con registros de identidad gubernamentales](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-how-it-works.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=3d5bb0df058265af0d8728cd60a78416)## El resultado de la coincidenciaCada servicio habilitado devuelve una validación por campo:| Campo | Resultados |
| - | - |
| `identification_number` | `full_match` · `partial_match` · `no_match` |
| `first_name` | `full_match` · `partial_match` · `no_match` |
| `last_name` | `full_match` · `partial_match` · `no_match` |
| `date_of_birth` | `full_match` · `no_match` |
| `address` | `full_match` · `partial_match` · `no_match` |El `match_type` agregado se resume así:- **`full_match`**: todos los campos solicitados coinciden con al menos una fuente.
- **`partial_match`**: hay coincidencia parcial; envíalo a una cola de revisión según las reglas de tu flujo.
- **`no_match`**: ninguna fuente confirmó los datos; normalmente se rechaza.## Cómo se obtiene la coincidencia (1×1 / 2×2)Ya no te pedimos que elijas de antemano "1×1" o "2×2": se derivan de cuántos servicios distintos devolvieron una coincidencia total con los datos de entrada:- **Resultado 1×1**: un servicio devolvió una coincidencia total (una única fuente autorizada confirmó los datos).
- **Resultado 2×2**: dos o más servicios devolvieron una coincidencia total (corroboración independiente; la mayor confianza que podemos expresar).Un flujo puede habilitar cualquier número de servicios por país; se te factura por cada servicio que realmente devolvió un resultado. Los servicios cuyos campos obligatorios no se pudieron extraer se omiten sin cargo.➡️ Consulta **[Métodos de coincidencia](https://docs.didit.me/core-technology/database-validation/database-validation-matching-methods.md)** para ver la lógica de decisión completa y cómo interactúa con `partialMatchAction` / `noMatchAction`.## Validación de base de datos biométricaLos registros civiles de algunos países publican una plantilla biométrica (un retrato o una huella dactilar). Cuando está disponible, combinamos la consulta al registro con una **coincidencia facial biométrica** con el selfie del usuario:- **Argentina (`arg_renaper`)**: coincidencia facial biométrica con la foto oficial de RENAPER. Cobertura del 100% de la población; todos los ciudadanos argentinos con DNI están en la base de datos.
- **Panamá (`pan_cedula_sib`, `pan_cedula_sib_plus`)**: coincidencia facial biométrica con el servicio SIB del Tribunal Electoral. SIB Plus es la variante de nivel superior, con umbrales biométricos más estrictos y metadatos de coincidencia más completos.Para estos servicios el campo `selfie` es **obligatorio**. Dentro de un flujo de sesión reutilizamos el selfie de la prueba de vida (el de mayor calidad) y recurrimos al retrato del documento como alternativa. Fuera de una sesión, al llamar a la API independiente (`POST /v3/database-validation/`, modo B más arriba), tú aportas el JPEG/PNG.## Enriquecimiento de identidad global`glb_identity_enrichment` es un servicio de validación de base de datos **global y solo independiente**. A partir de un correo electrónico y/o un número de teléfono, resuelve las personas asociadas (nombres, fechas de nacimiento, direcciones, teléfonos, correos electrónicos y documentos nacionales) y devuelve una puntuación de coincidencia de nombre, asignada a los [códigos de resultado](https://docs.didit.me/core-technology/database-validation/database-validation-outcome-codes.md) estándar `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (con el `match_type` correspondiente de `full_match` / `partial_match` / `no_match`).Como es un servicio global (`GLB`) basado en correo electrónico o teléfono y no en el país emisor de un documento, **no está disponible en el constructor de flujos**. Llámalo directamente a través de la API independiente con `issuing_state` definido como `GLB`:```json theme={null}
POST /v3/database-validation/
{
  "issuing_state": "GLB",
  "services": ["glb_identity_enrichment"],
  "email": "john.doe@example.com",
  "phone": "+14155552671"
}
```Se factura a **\$0.20 por solicitud** (solo se cobra cuando el proveedor devuelve un resultado).## ConfiguraciónLa validación de base de datos se configura por flujo desde la Consola. Para cada país eliges los servicios concretos que quieres ejecutar; los campos de entrada obligatorios y opcionales se derivan de la unión de esos servicios. La acción que se aplica a los resultados `partial_match` y `no_match` se configura por separado y puede ser `approve`, `review` o `decline`.![Ajustes de la consola de validación de base de datos de Didit para elegir servicios de registro por país y reglas de resultado](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-console.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2e1ac27f07fa9ca9c54108c6fd19a6b3)## Notificaciones de disponibilidadLos registros gubernamentales y otras fuentes se caen de vez en cuando. Mientras una base de datos no está disponible, las comprobaciones contra ella no devuelven respuesta y no se facturan. Dentro de un flujo, el servicio se resuelve como [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/core-technology/database-validation/database-validation-outcome-codes). En la API independiente, la misma caída llega en una de tres formas, así que lee los resultados por servicio **y** `database_validation.errors[]`, nunca solo el estado HTTP:- `200` con `outcome_code: "REGISTRY_UNAVAILABLE"` en ese servicio dentro de `validations`, cuando Didit conservó un resultado que informar para él.
- `200` con ese servicio en `database_validation.errors[]` como `code: "empty_provider_response"`, `retryable: true`, cuando no produjo ninguna respuesta utilizable y otro servicio seleccionado sí. El servicio fallido no aparece entonces en `validations` ni en `services_used`, así que `errors[]` es el único lugar donde figura.
- `502` con `validation_errors[].code: "empty_provider_response"` y `retryable: true`, cuando ningún servicio seleccionado devolvió un resultado utilizable (consulta [entrada rechazada y resultados no disponibles](https://docs.didit.me/standalone-apis/database-validation.md#rejected-input-and-unavailable-results)).El `status` general sigue a los servicios que sí respondieron, así que por sí solo no es una señal fiable de caída. Una solicitud que se queda sin nada que comparar pasa a `In Review`, pero una solicitud que seleccionó varios servicios puede devolver `Approved` por la coincidencia de otro servicio mientras una de sus fuentes no estaba disponible. Reintenta el servicio fallido indicado en `errors[]` en lugar de toda la solicitud.Ninguna de estas formas dice nada sobre la persona que se está verificando.Didit vigila los resultados en vivo de las comprobaciones reales, base de datos por base de datos, y envía un correo a tu organización cuando una interrupción es sostenida y no un único fallo aislado:| Correo | Cuándo se envía | Qué te indica |
| - | - | - |
| **Interrupción de una base de datos** | Una base de datos lleva fallando al menos diez minutos, con casi todas las comprobaciones de ese periodo sin respuesta. Una ráfaga breve o un solo fallo nunca lo activan. | La base de datos y el país afectados y cuándo se observaron los primeros fallos. Las comprobaciones pueden no devolver resultado hasta que se restablezca el acceso; no significa que las identidades enviadas no sean válidas. |
| **Acceso a la base de datos restablecido** | Las comprobaciones reales llevan respondiendo de nuevo al menos cinco minutos sin fallos. Los periodos sin actividad nunca cuentan como recuperación, así que una base de datos con poco tráfico tarda más en confirmar ambos estados. | Cuándo se confirmó la recuperación. Las verificaciones que no pudieron completarse durante la interrupción **no** se reprocesan automáticamente: revísalas y vuelve a intentarlas. |Los avisos se envían a los miembros y contactos de facturación de cada organización que ejecutó una comprobación contra esa base de datos exacta en las 48 horas anteriores. No hace falta configurar nada y no hay suscripción voluntaria. El tráfico del sandbox nunca los activa, y tampoco los fallos causados por los datos que enviaste (entradas rechazadas o mal formadas) ni los servicios que funcionan con credenciales que tu propia organización conecta. Una comprobación respondida mediante una fuente alternativa cuenta como disponible, igual que una ausencia de coincidencia concluyente.## Precios: paga solo por lo que usasLa validación de base de datos se factura **por consulta correcta y por servicio**, a la tarifa publicada para ese servicio. Las tarifas van desde **\$0.05** por comprobación (República Dominicana mediante la Junta Central Electoral) hasta **\$7.00** para las fuentes especializadas más caras. Muchas consultas a registros gubernamentales están en la franja de **USD 0.20 a USD 0.30**, pero bastantes cuestan bastante más porque la propia fuente cobra más: el documento nacional de identidad de Finlandia (`fin_national_id`) cuesta **\$2.10** por consulta correcta. Calcula el precio de un país a partir de su propia fila en la [tabla de precios](https://docs.didit.me/getting-started/database-validation-pricing.md), nunca a partir de un rango. No hay mínimos mensuales, compromisos ni comisiones de plataforma.Solo pagas cuando un servicio devuelve un resultado. Los servicios que se omiten por falta de datos de entrada no se facturan, y tampoco un servicio cuya llamada a la fuente falla: un error del registro o un registro inaccesible (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) significa que la consulta nunca se respondió, así que no es un resultado facturable.Cada consulta correcta a un registro se cobra desde la primera, ya se ejecute dentro de un flujo o mediante la API independiente `POST /v3/database-validation/`. Se paga con el crédito de tu plan o con el saldo recargado, como cualquier otra comprobación, y el descuento de tu plan se aplica a su precio completo. Consulta la [página de precios](https://docs.didit.me/getting-started/pricing.md#discounts).➡️ [Precios de la validación de base de datos](https://docs.didit.me/getting-started/database-validation-pricing.md) · [Regístrate y obtén una clave de API](https://business.didit.me/)## Todos los servicios

\<table><thead><tr><th>Country</th>
            \<th>ISO3</th>
            \<th>Service</th>
            \<th>Description</th>
            \<th>Price (USD)</th></tr></thead>
        \<tbody /></table>

## Sigue leyendo- [Métodos de coincidencia](https://docs.didit.me/core-technology/database-validation/database-validation-matching-methods.md): cómo se obtienen los resultados 1×1 / 2×2 y cómo reaccionar ante ellos.
- [Códigos de resultado](https://docs.didit.me/core-technology/database-validation/database-validation-outcome-codes.md): la lista completa de códigos de respuesta de los proveedores (fallecido, menor de edad, documento no encontrado, discrepancia biométrica, …) y cómo se asignan a las decisiones de la sesión.
- [Advertencias](https://docs.didit.me/core-technology/database-validation/database-validation-warnings.md): lo que mostramos cuando un servicio no puede ejecutarse por falta de datos.
- [Informes](https://docs.didit.me/core-technology/database-validation/database-validation-report.md): exportaciones mensuales de facturación por servicio con país, ID de servicio, uso, precio unitario y coste total.
- [Países compatibles](https://docs.didit.me/core-technology/database-validation/database-validation-supported-countries.md): una vista en tabla estática de todos los países que cubrimos hoy.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.