> ## 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 = () =>
{WARNING_TYPES.map(w =>
{w.icon}
{w.type}
{w.description}
)}
; 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), the document itself cannot be checked (it does not carry the identifier the configured services need — e.g. a passport without a national ID number), 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 five 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, the superseded-document risk and the not-applicable risk 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. | | No Match Action | `DATABASE_VALIDATION_DOCUMENT_SUPERSEDED` | Shares the **No Match Action** setting — there is no separate knob. The registry contradicted what was submitted, so an organization that declines on no-match declines on a stale credential too. | | Not Applicable Action | `DATABASE_VALIDATION_NOT_APPLICABLE` | `NO_ACTION` (default) records the warning without affecting status; `REVIEW` sets the feature to **In Review**; `DECLINE` declines. Fires when the document cannot be checked at all — it does not carry the identifier the configured services query by (e.g. a passport without a national ID number). | 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_NOT_APPLICABLE` | Database validation not applicable for this document | The document provided does not carry the identifier the configured database service(s) require (`match_type` stays `null`) — for example, a Brazilian passport carries no CPF, so the CPF registry cannot be queried. This is expected for the document type and does not indicate a problem with the document. `additional_data` carries the per-service skip summary. **You are not charged** when this warning fires. Action configurable (default `NO_ACTION`). | | `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). | | `DATABASE_VALIDATION_DOCUMENT_SUPERSEDED` | Superseded document edition | A service returned `DOCUMENT_SUPERSEDED`: the registry confirmed the person, but the edition of the document presented is not the one on file — a newer edition has since been issued. Raised independently of `match_type`, which stays `full_match` because every personal field did match, so the finding would otherwise be invisible. `additional_data` names the services that reported it. Follows the **No Match Action** setting. | `COULD_NOT_PERFORM_DATABASE_VALIDATION` covers two different situations, and the warning's `long_description` (and, for a per-service failure, `database_validation_errors[].message`) now states which one applied instead of a single generic sentence: the screened data was missing or malformed before any service could be queried, or a service was queried and did not return a usable result. In the second case, when the registry reported its own diagnostic detail for that attempt, that detail is included in the message so you don't have to contact support to learn why. The upstream service is never named in the response. When `COULD_NOT_PERFORM_DATABASE_VALIDATION` or `DATABASE_VALIDATION_NOT_APPLICABLE` 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. This also works when the not-applicable action declined the session, so a declined session can be remediated by correcting the data. For `DATABASE_VALIDATION_NOT_APPLICABLE` the re-run helps when the document can carry the identifier but it wasn't read (for example, a residence card whose national ID number wasn't extracted); document types that never carry the identifier (for example, passports without a national ID number) keep the warning. **No charge** is applied for skipped services; you only pay when a service returns a billable result. ## 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: ## 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.