Skip to main content
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) 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 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

SettingRisk codeBehavior
No Match ActionDATABASE_VALIDATION_NO_MATCHREVIEW (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 ActionDATABASE_VALIDATION_PARTIAL_MATCHNO_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 for the full decision logic that derives 1×1 / 2×2 outcomes.

​
Warnings produced

TagShort descriptionDescription
COULD_NOT_PERFORM_DATABASE_VALIDATIONCould not perform database validationNo 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_MATCHDatabase validation partial matchThe 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_MATCHDatabase validation no matchThe 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).
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.

​
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: