> ## 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.

# Database Validation Warnings

> Reference for every Database Validation warning: COULD_NOT_PERFORM_DATABASE_VALIDATION, partial or no match, registry unreachable, and missing fields.

export const WarningTypes = () => <div style={{
  display: "flex",
  flexDirection: "column",
  gap: "12px",
  margin: "16px 0"
}}>
    {WARNING_TYPES.map(w => <div key={w.type} style={{
  display: "flex",
  alignItems: "flex-start",
  gap: "12px",
  padding: "12px 16px",
  borderRadius: "8px",
  background: w.bg
}}>
        <span style={{
  fontSize: "16px",
  lineHeight: "24px"
}}>{w.icon}</span>
        <div>
          <div style={{
  fontWeight: 600,
  color: w.color,
  marginBottom: "2px"
}}>
            <code style={{
  background: "transparent",
  color: w.color,
  fontWeight: 600,
  padding: 0
}}>
              {w.type}
            </code>
          </div>
          <div style={{
  fontSize: "14px",
  lineHeight: "20px",
  color: "#374151"
}}>
            {w.description}
          </div>
        </div>
      </div>)}
  </div>;

Didit's [Database Validation](/core-technology/database-validation/overview) feature verifies identity data against authoritative civil registries — RENAPER (Argentina), Receita Federal (Brazil), Tribunal Electoral (Panama, biometric), Junta Central Electoral (Dominican Republic), and more — billed per successful query with no monthly minimums.

When no service can run (required fields missing or malformed, registry unavailable) or the aggregate outcome is non-conclusive (partial match, no match), the feature emits a **warning** on the session. If the issuing state isn't enabled in the workflow at all, the step is skipped silently with no warning and no charge. This page documents every warning code, what triggers it, and how to configure the workflow response.

## Overview

Warnings are produced both in workflow sessions and by the standalone API (`POST /v3/database-validation/`). All three risks are tagged with feature `DATABASE_VALIDATION`, appear on the report under `database_validations[].warnings[]`, and follow the standard [warning object](/reference/data-models#warning-object) shape (`feature`, `risk`, `additional_data`, `log_type`, `short_description`, `long_description`, `node_id`).

There are no hard auto-decline triggers for Database Validation. The two match-outcome risks map to a **configurable action** (`DECLINE`, `REVIEW`, or `NO_ACTION`); `COULD_NOT_PERFORM_DATABASE_VALIDATION` is the one fixed behavior — it always routes the feature to **In Review**.

## Configurable risks

| Setting              | Risk code                           | Behavior                                                                                                                                                                                                                     |
| -------------------- | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| No Match Action      | `DATABASE_VALIDATION_NO_MATCH`      | `REVIEW` (workflow default) sets the feature to **In Review**; `DECLINE` declines; `NO_ACTION` records the warning without affecting status. The standalone API's `no_match_action` parameter defaults to `DECLINE` instead. |
| Partial Match Action | `DATABASE_VALIDATION_PARTIAL_MATCH` | `NO_ACTION` (default) records the warning without affecting status; `REVIEW` sets the feature to **In Review**; `DECLINE` declines.                                                                                          |

The configured action also drives the warning's `log_type`: `DECLINE` → `error`, `REVIEW` → `warning`, `NO_ACTION` → `information`.

The match outcome itself is aggregated from the per-service `validation` entries (any full match → `full_match`; else any partial → `partial_match`; else `no_match`) — see [Matching methods](/core-technology/database-validation/database-validation-matching-methods) for the full decision logic that derives 1×1 / 2×2 outcomes.

## Warnings produced

| Tag                                     | Short description                     | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
| --------------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `COULD_NOT_PERFORM_DATABASE_VALIDATION` | Could not perform database validation | No service returned a usable result (`match_type` stays `null`) — typically because required fields are missing or malformed, or the registry returned an error. `additional_data` carries the per-service skip summary (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); the standalone API uses `{ "validation_errors": [...] }` instead. **You are not charged** when this warning fires; the feature moves to **In Review** until the data is corrected. |
| `DATABASE_VALIDATION_PARTIAL_MATCH`     | Database validation partial match     | The aggregate `match_type` is `partial_match` — some screened fields matched the registry but not all of them. Action configurable (default `NO_ACTION`).                                                                                                                                                                                                                                                                                                                                                                                                  |
| `DATABASE_VALIDATION_NO_MATCH`          | Database validation no match          | The aggregate `match_type` is `no_match` — the registry could not confirm the screened identity. Action configurable (default `REVIEW` in workflows, `DECLINE` on the standalone API).                                                                                                                                                                                                                                                                                                                                                                     |

<Note>
  When `COULD_NOT_PERFORM_DATABASE_VALIDATION` fires in a workflow session, the check is automatically re-triggered once the missing data is filled in on the session detail page in the Console — saving the field re-runs the validation, and the warning is removed on success. The feature status stays `In Review` until the validation succeeds. **No charge** is applied for skipped services; you only pay when a service returns a billable result.
</Note>

## Example

```json theme={null}
{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}
```

## Warning types

Each risk is assigned a severity based on your application's configuration. Severities fall into three categories:

<WarningTypes />

## Related

* [Database Validation overview](/core-technology/database-validation/overview) — how the feature works end-to-end and supported registries.
* [Database Validation report](/core-technology/database-validation/database-validation-report) — full response shape including per-service `validations[]`.
* [Matching methods](/core-technology/database-validation/database-validation-matching-methods) — how 1×1 / 2×2 outcomes (`validation_type: one_by_one` / `two_by_two`) are derived from per-service matches.
* [Outcome codes](/core-technology/database-validation/database-validation-outcome-codes) — full per-result taxonomy with country-specific detail codes.
* [Supported countries & services](/core-technology/database-validation/database-validation-supported-countries) — every live registry, required fields and per-call price.
* [Data models — database validation](/reference/data-models#database-validation) — canonical field-by-field schema.