{prompt.trim()}| Country | ISO3 | Service | Description | Price (USD) |
|---|---|---|---|---|
| {row.label} | ||||
| {row.country_name} | {row.country_iso3} |
{row.service_name}
{row.service_id}
|
{row.description} | ${row.default_price_usd.toFixed(2)} |
Hover any highlighted country to see its services and per-call pricing.
{false && active &&{s.service_id}
{s.price != null && · {formatPrice(s.price)}}
## The match outcome
Each enabled service returns a per-field validation:
| Field | Outcomes |
| - | - |
| `identification_number` | `full_match` · `partial_match` · `no_match` |
| `first_name` | `full_match` · `partial_match` · `no_match` |
| `last_name` | `full_match` · `partial_match` · `no_match` |
| `date_of_birth` | `full_match` · `no_match` |
| `address` | `full_match` · `partial_match` · `no_match` |
The aggregated `match_type` rolls up to:
* **`full_match`** — every requested field agrees with at least one source.
* **`partial_match`** — some agreement; route to a review queue per your workflow rules.
* **`no_match`** — no source confirmed the data; usually decline.
## How matching is derived (1×1 / 2×2)
We do not ask you to pre-pick "1×1" or "2×2" anymore — those are derived from how many distinct services full-matched the input data:
* **1×1 outcome** — one service returned a full match (a single authoritative source confirmed the data).
* **2×2 outcome** — two or more services returned a full match (independent corroboration; the highest confidence we can express).
A workflow can enable any number of services per country; you are billed per service that actually returned a result. Services whose required fields couldn't be extracted are skipped with no charge.
➡️ See **[Matching Methods](./database-validation-matching-methods)** for the full decision logic and how it interacts with `partialMatchAction` / `noMatchAction`.
## Biometric Database Validation
Some countries' civil registries publish a biometric template (a portrait or a fingerprint). When that's available, we pair the registry lookup with a **biometric face-match** against the user's selfie:
* **Argentina (`arg_renaper`)** — biometric face-match against the official RENAPER photo on file. 100% population coverage; every Argentine citizen with a DNI is in the database.
* **Panama (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — biometric face-match against the Tribunal Electoral SIB service. SIB Plus is the elevated-tier variant with stronger biometric thresholds and richer match metadata.
For these services the `selfie` field is **required**. Inside a session flow we re-use the liveness selfie (highest quality) and fall back to the document portrait. Outside a session, when calling the standalone API (`POST /v3/database-validation/`, Mode B above), you supply the JPEG/PNG yourself.
## Global identity enrichment
`glb_identity_enrichment` is a **global, standalone-only** Database Validation service. From an email and/or phone number it resolves associated persons (names, dates of birth, addresses, phones, emails and national IDs) and returns a name-match score, mapped to the standard [outcome codes](/core-technology/database-validation/database-validation-outcome-codes) `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (with the corresponding `match_type` of `full_match` / `partial_match` / `no_match`).
Because it is a global (`GLB`) service keyed on email/phone rather than a document's issuing country, it is **not available in the workflow builder**. Call it directly through the standalone API with `issuing_state` set to `GLB`:
```json theme={null}
POST /v3/database-validation/
{
"issuing_state": "GLB",
"services": ["glb_identity_enrichment"],
"email": "john.doe@example.com",
"phone": "+14155552671"
}
```
It is billed at **\$0.20 per request** (charged only when the provider returns a result).
## Configuration
Database Validation is configured per-workflow from the Console. For each country you select the specific services you want to run; required and optional input fields are derived from the union of those services. The action taken on `partial_match` and `no_match` outcomes is configured separately and can be `approve`, `review`, or `decline`.
## Availability notifications
Government registries and other sources go down from time to time. While a database is unreachable, checks against it return no answer and are not billed. Inside a workflow the service resolves to [`REGISTRY_UNAVAILABLE`](/core-technology/database-validation/database-validation-outcome-codes). On the standalone API the same outage arrives in one of three shapes, so read the per-service outcomes **and** `database_validation.errors[]`, never the HTTP status on its own:
* `200` with `outcome_code: "REGISTRY_UNAVAILABLE"` on that service in `validations`, when Didit kept a result to report for it.
* `200` with that service in `database_validation.errors[]` as `code: "empty_provider_response"`, `retryable: true`, when it produced no usable answer at all and another selected service did. The failed service is then absent from `validations` and from `services_used`, so `errors[]` is the only place it appears.
* `502` with `validation_errors[].code: "empty_provider_response"` and `retryable: true`, when no selected service returned a usable result (see [rejected input and unavailable results](/standalone-apis/database-validation#rejected-input-and-unavailable-results)).
The overall `status` follows the services that did answer, so it is not a reliable outage signal on its own. A request left with nothing to compare goes to `In Review`, but a request that selected several services can come back `Approved` on another service's match while one of its sources was unavailable. Retry the failed service from `errors[]` rather than the whole request.
None of these shapes says anything about the person being verified.
Didit watches the live results of real checks, database by database, and emails your organization when an interruption is sustained rather than a single failed request:
| Email | When it is sent | What it tells you |
| - | - | - |
| **Database interruption** | A database has been failing for at least ten minutes, with almost every check in that period left unanswered. A short burst or a single failure never triggers it. | The database and country affected and when the failures were first observed. Checks may return no result until access is restored; this does not mean the submitted identities are invalid. |
| **Database access restored** | Real checks have been answering again for at least five minutes with no failures. Quiet periods never count as recovery, so a low-traffic database takes longer to confirm both states. | When recovery was confirmed. Verifications that could not complete during the interruption are **not** reprocessed automatically: review them and retry. |
The notices go to the members and billing contacts of every organization that ran a check against that exact database in the previous 48 hours. Nothing needs to be configured and there is no opt-in. Sandbox traffic never triggers them, and neither do failures caused by the data you sent (rejected or malformed input) or by services that run on credentials your own organization connects. A check that was answered through a fallback source counts as available, and so does a conclusive no-match.
## Pricing — pay only for what you use
Database Validation is billed **per successful query, per service**, at the rate published for that service. Rates run from **\$0.05** per check (Dominican Republic via Junta Central Electoral) up to **\$7.00** for the most expensive specialist sources. Many government registry lookups sit in the **USD 0.20 to USD 0.30** band, but a good number cost considerably more because the source itself charges more — Finland National ID (`fin_national_id`) is **\$2.10** per successful query. Price a country from its own row in the [pricing table](/getting-started/database-validation-pricing), never from a range. There are no monthly minimums, commitments, or platform fees.
You only pay when a service returns a result. Services that skip because of missing input data are not billed, and neither is a service whose source call itself fails - a registry error or an unreachable registry (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) means the query was never answered, so it's not a chargeable result.