Database Validation Warnings

Didit’s Database Validation 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 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 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

{
  "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:

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

Authentication

Verification

Monitoring

Platform

Overview

Configurable risks

Warnings produced

Example

Warning types

​Overview

​Configurable risks

​Warnings produced

​Example

​Warning types

​Related

Overview

Configurable risks

Warnings produced

Example

Warning types

Related