Resolves persons (names, DOB, addresses, phones, emails, national IDs) and a name-match score from an email and/or phone number via Monnai's global risk-insights network. Billed per conclusive result. Didit exposes this service through `POST /v3/database-validation/` so you can screen the submitted data against the connected identity network and receive normalized match results. This is a third-party enrichment network, not an authoritative government registry — do not present its results as primary-source verification. ## Coverage * **Coverage:** 50+ markets * **Country:** Global * **Service ID:** `glb_identity_enrichment` * **Data domain:** Identity * **Category:** IdentityEnrichment ## Inputs | Field | Required | Example | | ---------------------- | -------: | ---------------------- | | `email` | No | `john.doe@example.com` | | `phone` | No | `+15550101000` | | `first_name` | No | `John` | | `last_name` | No | `Doe` | | `full_name` | No | `John Doe` | | `country_of_residence` | No | `US` | | `vendor_data` | No | `user-1234` | * **Required inputs:** — * **Optional inputs:** `email`, `phone`, `first_name`, `last_name`, `full_name`, `country_of_residence`, `vendor_data` * **Consent:** Required * **Workflow availability:** Standalone API only * **Coverage:** 50+ markets * **Price:** \$0.20 per successful query ## Body parameters ISO 3166-1 alpha-3 country code for this database service. Example: `GLB` Array containing this service ID. Pinning the service keeps the request scoped to this exact database. Example: `glb_identity_enrichment` Explicit end-user consent for this service. Example: `true` Email address. Example: `john.doe@example.com` Phone number in international format. Example: `+15550101000` Given name to validate. Example: `John` Family name to validate. Example: `Doe` Full legal name to validate. Example: `John Doe` Optional ISO 3166-1 alpha-2 country of residence. Only used to focus the identity lookup. Example: `US` Your stable user reference for this person, such as your internal user ID. Didit uses it to link standalone checks to the same end user and reduce duplicate-detection noise. Example: `user-1234` ## Input rules & validation notes * Provide at least one of `email` or `phone` - they are the lookup keys. A request with neither cannot perform an enrichment lookup and is rejected before source lookup (not charged). * Add `full_name` (or `first_name` + `last_name`) whenever you have it - the name is what the returned match score is computed against. * `country_of_residence` is an ISO 3166-1 alpha-2 code used to focus the lookup. * Didit validates required fields before calling the database. Requests rejected before source lookup are not charged. ## How to call it ```bash cURL theme={null} curl -X POST "https://verification.didit.me/v3/database-validation/" \ -H "x-api-key: YOUR_API_KEY" \ -F "issuing_state=GLB" \ -F "services=glb_identity_enrichment" \ -F "vendor_data=user-1234" \ -F "consent=true" \ -F "email=john.doe@example.com" \ -F "phone=+15550101000" \ -F "full_name=John Doe" \ -F "country_of_residence=US" ``` Every successful call returns HTTP `200`. The **`outcome_code`** field tells you what actually happened — distinguishing, for example, a real biometric mismatch (`BIOMETRIC_NO_MATCH`) from a selfie that could not be read (`BIOMETRIC_IMAGE_UNUSABLE`). The `status` shown is the default feature status; your configured [Partial Match / No Match actions](/core-technology/database-validation/database-validation-warnings) can override it. **`MATCH`** — Persons were found for the submitted email/phone and the best person's name matched the submitted name (name-match score at or above the match threshold). ```json 200 OK — MATCH theme={null} { "request_id": "req_01H…", "status": "Approved", "issuing_state": "GLB", "match_type": "full_match", "validations": [ { "outcome_code": "MATCH", "service_id": "glb_identity_enrichment", "service_name": "Global - Identity Enrichment (Monnai)", "source_data": { "first_name": "John", "last_name": "Doe", "persons_found": 2 }, "validation": { "full_name": "full_match" } } ] } ``` **`NO_MATCH`** — Persons were found for the submitted email/phone, but none of their names matched the submitted name. When no person is found at all the outcome is DOCUMENT\_NOT\_FOUND; when persons are found but no name was submitted to score against, it is INCONCLUSIVE. ```json 200 OK — NO_MATCH theme={null} { "request_id": "req_01H…", "status": "Declined", "issuing_state": "GLB", "match_type": "no_match", "validations": [ { "outcome_code": "NO_MATCH", "service_id": "glb_identity_enrichment", "service_name": "Global - Identity Enrichment (Monnai)", "source_data": { "first_name": "Jane", "last_name": "Smith", "persons_found": 3 }, "validation": { "full_name": "no_match" } } ] } ``` ## Returned data The exact fields surfaced in `source_data` depend on what the registry returns. The generated example for `glb_identity_enrichment` currently documents this normalized shape: * `first_name` * `last_name` * `persons_found` ## Pricing & SLAs Global - Identity Enrichment (Monnai) queries are billed only when Didit receives a conclusive result from the validation source. * **Per-call price:** \$0.20 USD. * **Billing:** per successful query. You are not charged when the registry is unreachable, when required fields are missing, or when the request is rejected before reaching the source. * **Latency:** typical p95 \< 2 s. * **Availability:** 99.9% per quarter on Didit's side; downstream source availability varies by country and dataset. ## Continue reading * [Global Database Validation overview](/getting-started/database-validation-pricing) * [Database Validation overview](/core-technology/database-validation/overview) * [Outcome Codes](/core-technology/database-validation/database-validation-outcome-codes)