Skip to main content
Didit’s Database Validation feature cross-references each user’s identity data against the authoritative source for that country — RENAPER (Argentina), Receita Federal (Brazil), Tribunal Electoral (Panama, with biometric face-match), Junta Central Electoral (Dominican Republic), and more — billed per successful query with no monthly minimums. Each entry in database_validations[] is one full Database Validation report — one run of a Database Validation node against one issuing state. The per-service registry outcomes live inside that entry’s validations[] sub-array. This page documents the JSON shape so you can parse match outcomes, registry source data, and biometric scores returned by each service.
Didit database validation report showing match types and registry response fields

​
Overview

A Database Validation report is produced every time a workflow node runs the Database Validation feature. Each entry in the database_validations[] array represents one node run against one issuing state; if the node runs multiple services for that country (for example CPF + CNH in Brazil), each service appears as a separate item inside the entry’s validations[] sub-array. Each report contains:
  • The overall feature status — a FeatureStatusChoices value (Not Finished, Approved, Declined, In Review).
  • A roll-up match_type (full_match, partial_match, no_match, or null when no service returned a usable result) aggregated across services via the matching method.
  • The issuing_state (ISO 3166-1 alpha-3) and the derived validation_type (one_by_one, two_by_two, or not_enabled — never null).
  • The screened_data block — the user-provided data that was sent to the registry.
  • A validations[] array — one entry per service that produced a result, with the catalog service_id/service_name, the vendor-neutral outcome_code, an optional outcome_detail, the per-field validation map and the cleaned source_data lifted from the registry response.
  • An errors[] array — per-service errors when a lookup failed or was skipped; the key is omitted entirely when there are no errors.
  • A warnings[] array — risk events emitted during the validation (see Database Validation warnings).
  • A node_id that identifies which workflow graph node produced the report (V3 sessions only).

​
Where it appears in API responses

The report appears as database_validations[] in GET /v3/session/{sessionId}/decision/ — always a JSON array, never a singular object. The array contains one entry per Database Validation node in the workflow graph; in turn, each entry’s validations[] sub-array contains one item per registry service that produced a result. 
{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "status": "Approved",
  "database_validations": [
    { "node_id": "feature_db_validation_1", "status": "Approved", "...": "..." }
  ]
}
A null value means no Database Validation step has run yet.

​
Schema

The canonical field-by-field schema lives on the Data models page. It is produced by DatabaseValidationV3Serializer. 
interface DatabaseValidation {
  node_id: string | null;
  status: "Not Finished" | "Approved" | "Declined" | "In Review"; // FeatureStatusChoices
  issuing_state: string | null;      // ISO 3166-1 alpha-3, e.g. "ARG"
  validation_type: "one_by_one" | "two_by_two" | "not_enabled"; // derived, never null
  match_type: "full_match" | "partial_match" | "no_match" | null; // null when no service returned a usable result
  screened_data: {                   // What we sent to the registry (varies by country/service)
    tax_number?: string;
    personal_number?: string;
    document_number?: string;
    first_name?: string;
    last_name?: string;
    date_of_birth?: string;          // YYYY-MM-DD
    selfie?: string;                 // Presigned URL (biometric services)
    cnh_qr_code_image?: string;      // Presigned URL (Brazil CNH QR + face match)
    document_image?: string;         // Presigned URL (services that take a document image)
    gender?: string;                 // Biometric registry services (e.g. Argentina RENAPER)
  };
  validations: Array<{
    // Catalog metadata
    service_id?: string;             // e.g. "arg_renaper"
    service_name?: string;           // e.g. "Argentina - DNI verification (RENAPER)"
    // Per-field match outcome — keys vary by service
    // (full_name, first_name, last_name, date_of_birth, identification_number, address, …)
    validation?: Record<string, "full_match" | "partial_match" | "no_match">;
    outcome_code?: string;           // Vendor-neutral outcome, see below
    outcome_detail?: string;         // Raw upstream status detail backing the outcome code
    source_data?: {                  // Cleaned registry record
      identification_number?: string;
      first_name?: string;
      last_name?: string;
      full_name?: string;
      date_of_birth?: string;
      place_of_birth?: string;
      gender?: string;
      nationality?: string;
      issue_date?: string;
      expiration_date?: string;
      photo?: string;                // Pre-signed JPEG URL
      signature?: string;            // Pre-signed JPEG URL
      face_match_score?: number;     // Biometric services only (0-100)
    };
  }>;
  errors?: Array<{                   // Omitted entirely when empty
    service_id: string;
    code?: string;                   // e.g. "invalid_screened_data", "empty_provider_response"
    message?: string;
    missing_required_fields?: string[];
    invalid_format_fields?: string[];
    field_reasons?: Record<string, string>;
  }>;
  warnings: Warning[];               // See /reference/data-models#warning-object
}

​
Status values

status uses the standard feature-level enum (see Status enums) — see the Status enum reference. The enum also defines Resub Requested, which is not produced by Database Validation in practice.
StatusMeaning
Not FinishedThe validation has not produced a result yet (initial state; also recorded when a standalone call fails across all services).
ApprovedNo risk fired, or the only fired risks are configured NO_ACTION (the partial-match default).
DeclinedA no-match or partial-match outcome whose configured action is DECLINE.
In ReviewA no-match or partial-match outcome whose configured action is REVIEW, or the validation could not run at all (COULD_NOT_PERFORM_DATABASE_VALIDATION — always review).
Custom per-node status rules are applied on top of this base status. See Database Validation warnings for the configurable actions and their defaults.

​
Outcome codes

Each entry in validations[] carries a vendor-neutral outcome_code — one of MATCH, PARTIAL_MATCH, NO_MATCH, DOCUMENT_NOT_FOUND, INVALID_DOCUMENT_FORMAT, INVALID_INPUT, MINOR_BLOCKED, DECEASED, BIOMETRIC_NO_MATCH, BIOMETRIC_IMAGE_UNUSABLE, INCONCLUSIVE, REGISTRY_UNAVAILABLE, REGISTRY_ERROR. Note the distinctions: NO_MATCH means the registry definitively did not confirm the data, INCONCLUSIVE means the registry could not determine either way (route to review, not decline), and BIOMETRIC_IMAGE_UNUSABLE is a technical selfie problem (retake) — unlike the definitive BIOMETRIC_NO_MATCH. See the full taxonomy and recommended handling on the Outcome codes page.

​
One entry per service

The validations[] array contains one item for each service that produced a result payload (a validation map, source_data, outcome_code, or outcome_detail). If your workflow runs multiple services for the same country (for example Brazil CPF + Brazil CNH), each one appears separately with its own service_id, outcome_code, and source_data. The roll-up match_type aggregates across all services (any full match → full_match; else any partial → partial_match; else no_match), and validation_type is derived from how many distinct services full-matched — see Matching methods.

​
Pre-signed image URLs

Image fields in source_data (photo, signature) and screened_data (selfie, cnh_qr_code_image, document_image) are returned as pre-signed URLs that expire — refresh by re-calling the decision endpoint. The raw upstream payload is intentionally not exposed via the API.

​
Examples

​
Approved — Brazil CPF status check (Receita Federal)

{
  "node_id": "feature_db_validation_1",
  "status": "Approved",
  "issuing_state": "BRA",
  "validation_type": "one_by_one",
  "match_type": "full_match",
  "screened_data": {
    "tax_number": "12345678900",
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1980-01-01"
  },
  "validations": [
    {
      "service_id": "bra_cpf",
      "service_name": "Brazil - CPF status check",
      "outcome_code": "MATCH",
      "outcome_detail": "200",
      "validation": {
        "full_name": "full_match",
        "date_of_birth": "full_match",
        "identification_number": "full_match"
      },
      "source_data": {
        "identification_number": "12345678900",
        "first_name": "JOHN",
        "last_name": "DOE",
        "date_of_birth": "1980-01-01",
        "lgpd_minor": false,
        "minor_under_16": false,
        "minor_under_18": false
      }
    }
  ],
  "warnings": []
}

​
Approved — Argentina DNI biometric (RENAPER)

For Argentina, the validation uses RENAPER with a biometric face-match. The response includes a face_match_score and additional identity fields returned by the registry. 
{
  "node_id": "feature_db_validation_1",
  "status": "Approved",
  "issuing_state": "ARG",
  "validation_type": "one_by_one",
  "match_type": "full_match",
  "screened_data": {
    "document_number": "12345678",
    "selfie": "https://<media-host>/sessions/<session-id>/selfie.jpg?X-Amz-Signature=...",
    "gender": "M",
    "first_name": "John",
    "last_name": "Doe"
  },
  "validations": [
    {
      "service_id": "arg_renaper",
      "service_name": "Argentina - DNI verification (RENAPER)",
      "outcome_code": "MATCH",
      "validation": {
        "full_name": "full_match",
        "identification_number": "full_match"
      },
      "source_data": {
        "identification_number": "12345678",
        "first_name": "John",
        "last_name": "Doe",
        "full_name": "John Doe",
        "date_of_birth": "1990-01-01",
        "tax_id": "20000000019",
        "tax_id_type": "CUIT",
        "face_match_score": 97
      }
    }
  ],
  "warnings": []
}

​
In Review — registry could not run

When no service returns a usable result — required fields missing or malformed, or the registry unreachable — match_type stays null, validation_type is not_enabled, a COULD_NOT_PERFORM_DATABASE_VALIDATION warning is emitted, and the feature moves to In Review until the data is corrected. No charge is applied for skipped services. 
{
  "node_id": "feature_db_validation_1",
  "status": "In Review",
  "issuing_state": "PAN",
  "validation_type": "not_enabled",
  "match_type": null,
  "screened_data": {
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "selfie": "https://<media-host>/sessions/<session-id>/selfie.jpg?X-Amz-Signature=..."
  },
  "validations": [],
  "errors": [
    {
      "code": "invalid_screened_data",
      "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.",
      "missing_required_fields": ["personal_number"],
      "service_id": "pan_cedula_sib_plus"
    }
  ],
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "COULD_NOT_PERFORM_DATABASE_VALIDATION",
      "additional_data": {
        "reason": "Database validation was skipped before any provider request because the screened data is incomplete or invalid.",
        "database_validation_errors": [
          {
            "code": "invalid_screened_data",
            "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.",
            "missing_required_fields": ["personal_number"],
            "service_id": "pan_cedula_sib_plus"
          }
        ],
        "missing_required_fields_by_service": { "pan_cedula_sib_plus": ["personal_number"] },
        "invalid_format_fields_by_service": {},
        "field_reasons_by_service": {}
      },
      "log_type": "warning",
      "short_description": "Could not perform database validation",
      "long_description": "The system couldn't perform the database validation, please fill the required fields for this country to automatically proceed with database validation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}
Fill the missing field from the session detail page in the Console — saving it re-triggers the check automatically and clears the warning on success.