--- title: "CURP Database Verification" slug: "curp-database-verification" description: "Validate CURP numbers in real-time with our CURP Database Verification solution, ensuring accurate identity checks for Mexican residents and compliance." updated: 2025-12-12T12:23:05Z published: 2025-12-12T12:23:05Z --- > ## Documentation Index > Fetch the complete documentation index at: https://devdocs.veriff.com/llms.txt > Use this file to discover all available pages before exploring further. # CURP Database Verification | Available via API | Available via SDK | Needs configuration on Veriff’s side | Needs a separate integration | Needs a separate webhook | | --- | --- | --- | --- | --- | | ✅ | ✅ | ✅ | ❌/✅* | ❌ | **CURP Database Verification** is a Mexican identity verification solution that validates government-issued CURP (*Clave Única de Registro de Población* or Unique Population Registry Code) numbers against the official Mexican government database. **CURP is an 18-character unique identification code** assigned to all Mexican citizens and residents, containing encoded information about the person's name, birthdate, gender, and place of birth. The solution performs real-time validation of demographic data including names, birth date, gender, and birth state to ensure accurate identity verification for Mexican residents and compliance with local regulations. **CURP Database Verification** is available via API, native SDKs and web SDK (aka webflow). ***CURP Database Verification** can be: - an add-on to your document + selfie IDV or document-only IDV, or - used separately as a stand-alone check, in which case the whole flow is performed via API. All session-related **info is returned via** decision webhook and can be **polled from different API endpoints**. The results of the verification can also be viewed in the **Veriff Customer Portal**, on sessions details page. If any **data** was **extracted from the document,**this data is provided in the webhook payload and GET /decision endpoint’s response payload. > [!NOTE] > Contact your **solutions engineer** for info and configuration. --- ## Prerequisites - You have an [integration set up](https://devdocs.veriff.com/v1/docs/how-to-create-an-integration) with Veriff - The **CURP** **database check is configured** for that integration **by your Solutions Engineer** - You have configured the [decision webhook](https://devdocs.veriff.com/v1/docs/decision-webhook) to get responses from Veriff (see the how-to in webhooks’ [Set up webhooks](https://devdocs.veriff.com/docs/webhooks-guide#set-up-webhooks) section) - If using the **API**, you are ready to collect and **send** Veriff your **end-user’s CURP number** - If using the API: - Veriff **strongly recommends** you collect and send **additional device/session data** for improved fraud mitigation - Veriff **strongly recommends** that you **create and send** us the endUserId or vendorData --- ## Flow overview The flow is a bit different, depending on the method (API or SDK) you are using to verify your end-users with Veriff. ### End-user data sources The CURP verification requires the CURP number to be provided **via initData only**. The CURP is passed through the `person.idNumber` parameter during session creation. #### initData This means that the checks are completed using the data you input during the session creation, i.e., the parameters you specify in the POST /sessions request. **Required parameter** `verification.person.idNumber` - the 18-character CURP number **CURP Format** - Length: 18 characters - Structure: AAAA######AAAAAA## - First 4 letters: surname and name initials - 6 digits: date of birth (YYMMDD) - 1 letter: gender (H=Male, M=Female) - 2 letters: state of birth code - Next 3 letters: first internal consonants of surnames and name - 2 digits: verification digits Example: `VISH560427MSRLNL06` ### Use via API #### Stand-alone CURP verification Use when you only need to verify an CURP credential without collecting document (and selfie) images. 1. Generate a verification session using the API keys and the `baseURL` of your CURP Database Verification integration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these) - Ensure that you send end-user’s CURP number in `person.idNumber` parameter **Sample request payload** ```bash curl -X POST \  --url '/v1/sessions/' \  -H 'X-AUTH-CLIENT: API-KEY' \  -H 'Content-Type: application/json' \  -d '{    "verification": {     "person": {       "idNumber": "VISH560427MSRLNL06"      }    }  }' ``` 1. Patch session status to****`submitted` status using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call **Sample request payload** ```bash curl -X PATCH \  --url '/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8' \  -H 'X-AUTH-CLIENT: API-KEY' \  -H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \  -H 'Content-Type: application/json' \  -d '{    "status": "submitted"  }' ``` 1. Check the decision data and/or session related info from the decision webhook and/or query the data from the [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] endpoint. #### CURP with document verification 1. Generate a verification session using the API keys and the `baseURL` of your CURP Database Verification integration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these) - Ensure that you send end-user’s CURP number in `person.idNumber` parameter - Veriff strongly recommends you create and send the `endUserId` or `vendorData`.’ - Veriff strongly recommends you collect and send additional session/device data via [POST sessions/{sessionid}/collected-data](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidcollected-data-1)[↗] for improved fraud detection. **Minimal request payload sample** ```bash curl -X POST \  --url '/v1/sessions/' \  -H 'X-AUTH-CLIENT: API-KEY' \  -H 'Content-Type: application/json' \  -d '{    "verification": {     "person": {       "idNumber": "VISH560427MSRLNL06"      },      "endUserId": "a1b2c35d-e8f7-6d5e-3cd2-a1b2c35db3d4"    }  }' ``` 1. Use your image-capturing method, or prepare previously collected end-user document / selfie image(s) 1. Upload the end-user's media via [POST /sessions/{sessionId}/media](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidmedia-3)[↗] call - The types of photos you need to send depends on if you are doing document-only IDV or document + selfie IDV. - Ensure that you pass correct image context type for the `image.context` parameter (see [Context types (image, video)](/v1/docs/context-types-image-video-1) for more info about image context types). **Sample request payload** ```bash curl -X POST \  --url '/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media' \  -H 'X-AUTH-CLIENT: API-KEY' \  -H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \  -H 'Content-Type: application/json' \  -d '{    "image": {      "data": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEA...",      "context": "document-front"    }  }' ``` 1. Patch session status to `submitted` status using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call **Sample request payload** ```bash curl -X PATCH \  --url '/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8' \  -H 'X-AUTH-CLIENT: API-KEY' \  -H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \  -H 'Content-Type: application/json' \  -d '{    "status": "submitted"  }' ``` 1. Check the decision data and/or session related info from the decision webhook and/or query the data from the [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] endpoint. Solution-specific overview of what to expect is provided below in [Solution-specific parameters](/v1/docs/curp-database-verification#solutionspecific-parameters) section. --- ## Find decision and/or session related info You can get the data from three sources: - Receive the decision webhook ([example below](/v1/docs/curp-database-verification#webhook-payload)) - GET /sessions/{sessionId}/decision ([example below](/v1/docs/curp-database-verification#api-call)) - View the session in Veriff Customer Portal Note that the decision webhook and GET /sessions/{sessionId}/decision payloads are identical. ### Solution-specific parameters All the CURP Database Verification results are returned in `additionalVerifiedData.officialDatabaseVerification.curp.validations` within the webhook payload. The verification includes three validation checks: 1. **Processing** - confirms the CURP verification request was successfully processed 2. **CURP is valid** - validates that the CURP exists in the official Mexican registry and is properly formatted 3. **CURP has risk factors** - checks for any risk indicators associated with the CURPWebhook payload Each check returns one of the following results: - `success` - the check passed successfully - `failure` - the check did not pass - `not_applicable` - the check is not relevant for this CURP ### Webhook payload > [!NOTE] > Below are a **sample** and an **explanation** of a **decision webhook** **payload for a minimal** **CURP Database Verification**. Depending on your integration configuration, the payload may contain additional parameters. To find more info about those parameters, see the [decision webhook](/v1/docs/decision-webhook) documentation. #### Sample request ```json {  "status": "success",  "verification": {    "acceptanceTime": "2025-10-21T13:12:32.520216Z",    "decisionTime": "2025-10-21T13:12:43.125995Z",    "code": 9001,    "id": "96d8c583-0855-43c2-b549-bf8824465835",    "vendorData": null,    "endUserId": null,    "status": "approved",    "additionalVerifiedData": {      "officialDatabaseVerification": {        "curp": {          "matchData": {            "dateOfBirth": "MATCH",            "fullName": "MATCH",            "gender": "NO_INPUT"          },          "validations": {            "processing": {              "result": "success"            },            "curpIsValid": {              "result": "success"            },            "curpHasRiskFactors": {              "result": "not_applicable"            },            "matching": {                "result": "sucess"            }          },          "registryResponse": {            "curp": "VISH560427MSRLNL06",            "paternalSurname": "VILLA",            "maternalSurname": "SANCHES",            "names": "GLORIA",            "gender": "MUJER",            "dob": "27/04/1956",            "nationality": "MEXICO",            "supportingDocument": "1",            "registrationEntity": "SONORA",            "registrationStateNumber": null,            "registrationMunicipalityKey": null,            "page": null,            "tome": null,            "book": null,            "minutesNumber": "02203",            "crip": "string",            "registrationEntity2": "HERMOSILLO",            "registrationYear": "1956",            "foreignRegistrationNumber": "string",            "letterFolio": "string",            "birthStateKey": "SONORA",            "issueEntityKey": "SONORA",            "curpStatus": "RNC",            "certificateFolio": "string"          }        }      }    },    "attemptId": "96d8c583-0855-43c2-b549-bf8824465835"  },  "technicalData": {    "ip": null  } } ``` #### Request properties explained - `status`: `string` Overall verification status , one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned`) - `verification`: `object` Contains all details of the verification session - `id`: `string` Unique session identifier - `attemptId`: `string` UUID v4 of the attempt which received a status (as. shown in `verification.status` field) - `code`: `number` Decision code (e.g., 9001 for approved) - `reason`: `string` or `null` Human-readable decline reason if applicable - `reasonCode`: `string` or `null` Machine-readable decline code if applicable - `decisionTime`: `string` ISO timestamp when the decision was made - `acceptanceTime`: `string` ISO timestamp when the session was accepted - `additionalVerifiedData`: `object` Contains the results of all validations - `officialDatabaseVerification`: `object` Contains the results of the database verification - `curp` : `object` Contains CURP verification results - `matchData`: `object` Optional, available only when matching validation is enabled for the integration. Shows how different end-user data types that were sent as initData or extracted from the document [match the data in the registry](/v1/docs/curp-database-verification#note-about-matchdata). - `dateOfBirth`: `string` Indicates if the date of birth data matches gender data in registry - `fullName`: `string` Indicates if the full name data matches gender data in registry - `gender`: `string` Indicates if the gender data matches gender data in registry - `validations` : `object` Contains validation check results - `processing` : Indicates processing validation result - `result`: `string` indicates if the request was properly processed, one of `success`, `failure` (there was an error when processing the request) or `not_applicable` (processing check was not configured). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `curpIsValid`: CURP validity validation result - `result`: `string` status of the validity validation check, one of `success`, `failure` (CURP does not exist, has a formatting issue, or is invalid) or `not_applicable` (validity check not configured). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `curpHasNoRiskFactors`: risk factors validation result - `result`: `string` status of the validation, one of `success`, `failure` (risk factors were detected) or `not_applicable` (no risk factors were found). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `matching`: `object` Optional, only available when the input data matching validation was enabled for the integration (`curp.matchData` parameter is included in the payload) - `result`: `string` Always `success`, irrespective of `matchData` results - `registryResponse` Object containing detailed information retrieved from the Mexican government registry. Fields below are optional and might not be present if the data is `null` from the provider. - `curp` : `string` The validated CURP number - `paternalSurname`: `string` Person's paternal surname from registry - `maternalSurname` : `string` Person's maternal surname from registry - `names` : `string` Person's given name(s) from registry - `gender` : `string` Gender indicator (H=Male, M=Female) - `dob` : `string` Date of birth from registry - `nationality` : `string` Nationality code - `supportingDocument` : `string` Type of supporting document used for CURP registration - `registrationEntity` : `string` Entity where the person was registered - `registrationStateNumber`: `string` State indicator where the person was registered - `registrationMunicipalityKey`: `string` Municipality indicator where the person was registered - `page` : `string` Page number from birth certificate (if applicable) - `tome` : `string` Tome number from birth certificate (if applicable) - `book` : `string` Book number from birth certificate (if applicable) - `minutesNumber` : `string` Minutes number from civil registry - `crip` : `string` CRIP identifier - `registrationEntity2` : `string` Secondary registration entity - `registrationYear` : `string` Year of registration - `foreignRegistrationNumber` : `string` Foreign registration indicator - `letterFolio` : `string` Letter folio from registration - `birthStateKey` : `string` - State of birth code - `issueEntityKey` : `string` - Entity that issued the CURP - `curpStatus` : `string` Current status of the CURP - `certificateFolio` : `string` Certificate information - `technicalData`: `object` Technical data object - `ip`: `string | null` IP of the device from which the verification was made ### API call > [!NOTE] > Below are a **sample** and an **explanation** of a **GET /decision** **API call payload for a minimal** **CURP Database Verification**. Depending on your integration configuration, the payload may contain additional parameters. To find more info about it, see the [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] documentation. #### Sample response ```json {  "status": "success",  "verification": {    "acceptanceTime": "2025-10-21T13:12:32.520216Z",    "decisionTime": "2025-10-21T13:12:43.125995Z",    "code": 9001,    "id": "96d8c583-0855-43c2-b549-bf8824465835",    "vendorData": null,    "endUserId": null,    "status": "approved",    "additionalVerifiedData": {      "officialDatabaseVerification": {        "curp": {          "matchData": {            "dateOfBirth": "MATCH",            "fullName": "MATCH",            "gender": "NO_INPUT"          },          "validations": {            "processing": {              "result": "success"            },            "curpIsValid": {              "result": "success"            },            "curpHasRiskFactors": {              "result": "not_applicable"            },            "matching": {                "result": "sucess"            }          },          "registryResponse": {            "curp": "VISH560427MSRLNL06",            "paternalSurname": "VILLA",            "maternalSurname": "SANCHES",            "names": "GLORIA",            "gender": "MUJER",            "dob": "27/04/1956",            "nationality": "MEXICO",            "supportingDocument": "1",            "registrationEntity": "SONORA",            "registrationStateNumber": null,            "registrationMunicipalityKey": null,            "page": null,            "tome": null,            "book": null,            "minutesNumber": "02203",            "crip": "string",            "registrationEntity2": "HERMOSILLO",            "registrationYear": "1956",            "foreignRegistrationNumber": "string",            "letterFolio": "string",            "birthStateKey": "SONORA",            "issueEntityKey": "SONORA",            "curpStatus": "RNC",            "certificateFolio": "string"          }        }      }    },    "attemptId": "96d8c583-0855-43c2-b549-bf8824465835"  },  "technicalData": {    "ip": null  } } ``` #### Response properties explained - `status`: `string` Overall verification status , one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned`) - `verification`: `object` Contains all details of the verification session - `id`: `string` Unique session identifier - `attemptId`: `string` UUID v4 of the attempt which received a status (as. shown in `verification.status` field) - `code`: `number` Decision code (e.g., 9001 for approved) - `reason`: `string` or `null` Human-readable decline reason if applicable - `reasonCode`: `string` or `null` Machine-readable decline code if applicable - `decisionTime`: `string` ISO timestamp when the decision was made - `acceptanceTime`: `string` ISO timestamp when the session was accepted - `additionalVerifiedData`: `object` Contains the results of all validations - `officialDatabaseVerification`: `object` Contains the results of the database verification - `curp` : `object` Contains CURP verification results - `matchData`: `object` Optional, available only when matching validation is enabled for the integration. Shows how different end-user data types that were sent as initData or extracted from the document [match the data in the registry](/v1/docs/curp-database-verification#note-about-matchdata). - `dateOfBirth`: `string` Indicates if the date of birth data matches gender data in registry - `fullName`: `string` Indicates if the full name data matches gender data in registry - `gender`: `string` Indicates if the gender data matches gender data in registry - `validations` : `object` Contains validation check results - `processing` : Indicates processing validation result - `result`: `string` indicates if the request was properly processed, one of `success`, `failure` (there was an error when processing the request) or `not_applicable` (processing check was not configured). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `curpIsValid`: CURP validity validation result - `result`: `string` status of the validity validation check, one of `success`, `failure` (CURP does not exist, has a formatting issue, or is invalid) or `not_applicable` (validity check not configured). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `curpHasNoRiskFactors`: risk factors validation result - `result`: `string` status of the validation, one of `success`, `failure` (risk factors were detected) or `not_applicable` (no risk factors were found). - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `matching`: `object` Optional, only available when the input data matching validation was enabled for the integration (`curp.matchData` parameter is included in the payload) - `result`: `string` Always `success`, irrespective of `matchData` results - `registryResponse` Object containing detailed information retrieved from the Mexican government registry. Fields below are optional and might not be present if the data is `null` from the provider. - `curp` : `string` The validated CURP number - `paternalSurname`: `string` Person's paternal surname from registry - `maternalSurname` : `string` Person's maternal surname from registry - `names` : `string` Person's given name(s) from registry - `gender` : `string` Gender indicator (H=Male, M=Female) - `dob` : `string` Date of birth from registry - `nationality` : `string` Nationality code - `supportingDocument` : `string` Type of supporting document used for CURP registration - `registrationEntity` : `string` Entity where the person was registered - `registrationStateNumber`: `string` State indicator where the person was registered - `registrationMunicipalityKey`: `string` Municipality indicator where the person was registered - `page` : `string` Page number from birth certificate (if applicable) - `tome` : `string` Tome number from birth certificate (if applicable) - `book` : `string` Book number from birth certificate (if applicable) - `minutesNumber` : `string` Minutes number from civil registry - `crip` : `string` CRIP identifier - `registrationEntity2` : `string` Secondary registration entity - `registrationYear` : `string` Year of registration - `foreignRegistrationNumber` : `string` Foreign registration indicator - `letterFolio` : `string` Letter folio from registration - `birthStateKey` : `string` - State of birth code - `issueEntityKey` : `string` - Entity that issued the CURP - `curpStatus` : `string` Current status of the CURP - `certificateFolio` : `string` Certificate information - `technicalData`: `object` Technical data object - `ip`: `string | null` IP of the device from which the verification was made #### Note about `matchData` - `MATCH` means that the input data matches registry data - `NO_MATCH` means the input data does not match registry data - `NO_INPUT` means no data was provided for the field - `NO_DATA` means the registry did not contain any info for this field ### Veriff Customer Portal You can find the verification session related info, including the decision, in the Veriff Customer Portal, under the webhooks tab. → *See*[*Review verification in Veriff Customer Portal*](/v1/docs/how-to-review-verification-in-veriff-customer-portal)*about how to view the session info in the Veriff Customer portal* --- ## Status and reason codes For an `approved` session, see: - `verification.code` about verification session decision code, one of `9001`, `9102`, `9103`, `9104`, `9121` - `verification.status` about verification status, one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned` If the CURP Database Verification session was `declined` or `resubmission_requested`, you can find additional information by checking: - `verification.reason` for the reason why the verification failed - `verification.reasonCode` for reason code of the failed verification and cross-reference it with [Granular reason codes (table)](/v1/docs/granular-reason-codes) --- ## Additional information ### Best practices - **CURP format validation**: validate the CURP format on your side before submitting to reduce API calls - **Error handling**: Implement proper error handling for all possible validation results - **Webhook security**: Secure your webhook endpoint and verify request signatures - **User experience**: Provide clear feedback to users about validation results --- ## FAQ #### What can I use the `registryResponse` data for? The `curpValidation.registryResponse` object contains the complete information retrieved from the Mexican government database. This data can be used for: **Identity matching** - Compare the registry data with information provided by your end-user **Additional verification** - Use fields like date of birth, gender, and name to perform additional checks **Record keeping** - Store the official government data for compliance purposes #### What are common use cases for CURP Database Verification? **CURP verification with document capture** Combine CURP verification with document capture for enhanced verification: - Create session with CURP in initData - Capture document images through SDK - Receive combined verification results **Validating user-provided information** Use the `registryResponse` data to validate information your user provided: - User provides name, date of birth, and CURP - Verify CURP through Veriff - Compare `registryResponse` fields with user-provided data - Make decision based on match level #### How to handle validation errors? If the CURP verification encounters issues, the validation results will reflect the problem: **Processing failed**: System error occurred during verification - Check CURP format - Verify API credentials - Fallback to another verification process - Contact Veriff support if issue persists **CURP is invalid**: The CURP does not exist or is malformed - Verify the CURP was entered correctly - Confirm with the user - Request a different identity document **Risk factors detected**: The CURP has associated risk indicators - Review your risk tolerance policies - Consider requesting additional verification - Follow your compliance procedures --- ## Changelog | Date | Description | | --- | --- | | Dec 12, 2025 | Broken links fixed and `x-hmac-signature` header restored to request payload examples | | Nov 27, 2025 | Intro section updated | | Nov 26, 2025 | Some missing payload parameters added | | Nov 19, 2025 | `curp.matchData` , `validations.matching` and [Note about matchDat](/v1/docs/curp-database-verification#note-about-matchdata)a added to webhook and API payloads sections | | Nov 17, 2025 | Webhook and API payload hierarchy updated API flow steps formatting changed | | Nov 13, 2025 | Payload indentation updated | | Nov 12, 2025 | Documentation published | Veriff customer back-office, a dashboard where you can see your end-users' verification data. Depending on your setup, you may be required to access the environment via station.veriff.com or hub.veriff.com. Always **check your sign-up email** and make sure that you **log in via correct address**. A UUID-format unique identifier ([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}) created by you for your end-user to link an end-user to their session(s). Cannot be resolved outside your environment. Veriff stores it only for identity verification and returns it unchanged in webhooks/API responses or as `null` if not provided. Strongly recommended if you already use UUID identifiers. Works as an alternative to `vendorData` in Biometric Authentication solution. A custom unique identifier (max 1,000 characters) created by you, containing only non-semantic data that can't be resolved outside your systems. Veriff returns it unchanged in webhooks/API responses or as `null` if not provided. It's referred to as "unique identifier" in Customer Portal and cannot be changed once set. Required for Fraud solutions (Cross Links check and Velocity Abuse check) and serves as an alternative to `endUserId` in Biometric Authentication when using non-UUID identifiers. A session during which the end-user is verified. It starts when a session is created, it can contain several attempts (i.e. steps of uploading media, sending additional data etc.) and it ends when a conclusive decision (“approved”, “declined”, “expired”/”abandoned”) is granted. Each verification session receives an unique ID, aka the **session ID**, which can be added to the API URL when making API requests.