Verifies Uruguayan Cédula data against Dirección Nacional del Registro de Estado Civil government records. Didit exposes this service through `POST /v3/database-validation/` so you can verify the submitted data against the authoritative source and receive normalized match results. ## Coverage * **Coverage:** 90-95% * **Country:** Uruguay * **Service ID:** `ury_cedula` * **Data domain:** Identity * **Category:** NationalIDRegistry ## Inputs | Field | Required | Example | | ----------------- | -------: | ------------ | | `personal_number` | Yes | `1111111` | | `date_of_birth` | Yes | `1990-01-01` | | `first_name` | No | `John` | | `last_name` | No | `Doe` | | `vendor_data` | No | `user-1234` | * **Required inputs:** `personal_number`, `date_of_birth` * **Optional inputs:** `first_name`, `last_name`, `vendor_data` * **Consent:** Not required * **Workflow availability:** Available in workflow * **Coverage:** 90-95% * **Price:** \$0.20 per successful query ## Body parameters ISO 3166-1 alpha-3 country code for this database service. Example: `URY` Array containing this service ID. Pinning the service keeps the request scoped to this exact database. Example: `ury_cedula` Country-specific personal identity number. Example: `1111111` Date of birth in `YYYY-MM-DD` format. Example: `1990-01-01` Given name to validate. Example: `John` Family name to validate. Example: `Doe` 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 * Uruguayan CI (7-9 digits) * `personal_number` must contain digits only; remove spaces, hyphens, and punctuation before sending the request. * `personal_number` must be 7-9 characters long. ## 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=URY" \ -F "services=ury_cedula" \ -F "vendor_data=user-1234" \ -F "personal_number=1111111" \ -F "date_of_birth=1990-01-01" ``` 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`** — The registry confirmed the identity and every checked field matched. ```json 200 OK — MATCH theme={null} { "request_id": "req_01H…", "status": "Approved", "issuing_state": "URY", "match_type": "full_match", "validations": [ { "outcome_code": "MATCH", "service_id": "ury_cedula", "service_name": "Uruguay - CI verification", "source_data": { "date_of_birth": "1990-01-01", "first_name": "John", "full_name": "John Doe", "identification_number": "SAMPLE-ID-12345", "last_name": "Doe" }, "validation": { "date_of_birth": "full_match", "identification_number": "full_match" } } ] } ``` **`PARTIAL_MATCH`** — The identification number was found but one or more personal fields (usually name or date of birth) did not fully match. ```json 200 OK — PARTIAL_MATCH theme={null} { "request_id": "req_01H…", "status": "In Review", "issuing_state": "URY", "match_type": "partial_match", "validations": [ { "outcome_code": "PARTIAL_MATCH", "service_id": "ury_cedula", "service_name": "Uruguay - CI verification", "source_data": { "date_of_birth": "1990-01-01", "first_name": "John", "full_name": "John Doe", "identification_number": "SAMPLE-ID-12345", "last_name": "Doe" }, "validation": { "date_of_birth": "no_match", "identification_number": "full_match" } } ] } ``` **`NO_MATCH`** — The registry returned no match for the submitted data. ```json 200 OK — NO_MATCH theme={null} { "request_id": "req_01H…", "status": "Declined", "issuing_state": "URY", "match_type": "no_match", "validations": [ { "outcome_code": "NO_MATCH", "service_id": "ury_cedula", "service_name": "Uruguay - CI verification", "source_data": { "date_of_birth": "NO_MATCH", "identification_number": "NO_MATCH" }, "validation": { "date_of_birth": "no_match", "identification_number": "no_match" } } ] } ``` ## Returned data The exact fields surfaced in `source_data` depend on what the registry returns. The generated example for `ury_cedula` currently documents this normalized shape: * `date_of_birth` * `first_name` * `full_name` * `identification_number` * `last_name` ## Pricing & SLAs Uruguay - CI verification 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 * [Uruguay Database Validation overview](/api-reference/database-validation/uruguay) * [Database Validation overview](/core-technology/database-validation/overview) * [Outcome Codes](/core-technology/database-validation/database-validation-outcome-codes)