Skip to main content

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.

Didit’s Database Validation verifies the identity data extracted from a user’s ID document against the authoritative source for that country — the national civil registry, tax authority, electoral roll, credit bureau or biometric registry that issued the document in the first place. Each check returns a per-field match (identification_number, first_name, last_name, date_of_birth, and address fields when the service uses them) plus an aggregated outcome and the underlying record details when available. It is the strongest defence against synthetic-identity fraud: a stolen real DNI or CPF will fail the registry lookup, and a fabricated number won’t be in the official database at all. Database Validation pairs with our biometric face-match in countries where the registry holds an official photo (Argentina via RENAPER, Panama via Tribunal Electoral SIB / SIB Plus) so you can confirm not just that a number is real, but that the person standing in front of the camera owns it.

​
Why Didit

  • Cheapest pay-per-call pricing. From $0.05 per check (Dominican Republic) up to $1.50 for premium-tier biometric services (Panama SIB Plus). No monthly minimums, no platform fees, no per-seat billing — only successful queries are charged.
  • Fastest to integrate. Sign up, grab an API key from the console, and you can call POST /v3/database-validation/ within minutes. No sales call, no procurement cycle, no proof-of-concept paperwork — Didit is fully self-service.
  • Direct hits to the authoritative source. RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — not aggregator scrapes.
  • Biometric face-match where the registry has an official photo on file. Higher-than-OCR confidence with no extra integration work.
  • Production-ready latency. p95 typically under 1.5 s end-to-end, 99.9% quarterly availability.

​
Global coverage

Hover any highlighted country to see every Database Validation service we run there, the data domain (Identity, Financial, Biometric, Address, Telecom, …) and the per-call price. Live countries are production-ready today; the rest are wired in on demand once a customer asks.
Don’t see your country? Reach out — our catalog tracks 60+ countries with hundreds of services that we activate on demand once a customer needs them. New integrations typically go live in 2–3 weeks.

​
How a Database Validation runs

A Database Validation never fires speculatively. It only runs when all of the following are true:
  1. The session’s ID Verification extracted an issuing_state from the document.
  2. That country has at least one Database Validation service enabled in the workflow.
  3. ID Verification successfully extracted every required field the chosen service needs.
If a service is enabled but the document didn’t yield the required fields (e.g. CPF wasn’t extractable from a smudged Brazilian RG), the service is skipped, you are not charged, and we raise a warning on the session. You can fill the missing field by hand from the session detail page in the Console — saving the field re-triggers the check automatically. For address-based services, Didit splits the ID document’s single address into structured address elements automatically:
Didit fieldMeaning
address_element_1Street address, including number and street type
address_element_2Optional unit, building, floor, or extra address line
address_element_3Suburb, district, locality, or neighborhood
address_element_4City, town, state, province, or region
address_element_5Postcode or postal code
When calling the standalone API, you can send either a single address or these structured fields directly. Structured fields win when both are present. Services that require address search need address_element_1 plus at least one other address element; if Didit cannot derive those from the workflow OCR address, the service is skipped and not billed. If the issuing state is not enabled at all, the step is skipped silently with no warning and no charge.
Didit database validation flow checking user data against government identity registries

​
The match outcome

Each enabled service returns a per-field validation:
FieldOutcomes
identification_numberfull_match · partial_match · no_match
first_namefull_match · partial_match · no_match
last_namefull_match · partial_match · no_match
date_of_birthfull_match · no_match
addressfull_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 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, you supply the JPEG/PNG yourself.

​
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.
Didit database validation console settings selecting per-country registry services and outcome rules

​
Pricing — pay only for what you use

Database Validation is billed per successful query, per service. The lowest tier starts at $0.05 per check (Dominican Republic via Junta Central Electoral). Standard government-registry checks cost $0.20–$0.30, and biometric premium tiers (Panama SIB Plus) cost $1.50. There are no monthly minimums, no commitments, no platform fees. You only pay when a service returns a result. Services that skip because of missing input data are not billed. ➡️ Database Validation Pricing · Sign up and get an API key

​
All services

​
Continue reading

  • Matching Methods — how 1×1 / 2×2 outcomes are derived and how to react to them.
  • Outcome Codes — the full list of provider response codes (deceased, minor, document not found, biometric mismatch, …) and how they map to session decisions.
  • Warnings — what we surface when a service can’t run due to missing data.
  • Reports — monthly per-service billing exports with country, service ID, usage, unit price and total cost.
  • Supported Countries — a static table view of every country we cover today.