CURP Database Verification

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.

Contact your solutions engineer for info and configuration.

Prerequisites

• You have an integration set up with Veriff

• The CURP database check is configured for that integration by your Solutions Engineer

• You have configured the decision webhook to get responses from Veriff (see the how-to in webhooks’ 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[↗] how to find these)

   • Ensure that you send end-user’s CURP number in person.idNumber parameter

Sample request payload

curl -X POST \
  --url '/v1/sessions/' \
  -H 'X-AUTH-CLIENT: API-KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "verification": {
     "person": {
       "idNumber": "VISH560427MSRLNL06"
      }
    }
  }'

2. Patch session status to submitted status using PATCH /sessions/{sessionId}[↗] call

Sample request payload

curl -X PATCH \
  --url '/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8' \
  -H 'X-AUTH-CLIENT: API-KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "status": "submitted"
  }'

3. Check the decision data and/or session related info from the decision webhook and/or query the data from the GET sessions/{sessionId}/decision[↗] 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[↗] 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[↗] for improved fraud detection.
  

Minimal request payload sample

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"
    }
  }'

2. Use your image-capturing method, or prepare previously collected end-user document / selfie image(s)

3. Upload the end-user's media via POST /sessions/{sessionId}/media[↗] 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) for more info about image context types).

Sample request payload

curl -X POST \
  --url '/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media' \
  -H 'X-AUTH-CLIENT: API-KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "image": {
      "data": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEA...",
      "context": "document-front"
    }
  }'

4. Patch session status to submitted status using PATCH /sessions/{sessionId}[↗] call

Sample request payload

curl -X PATCH \
  --url '/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8' \
  -H 'X-AUTH-CLIENT: API-KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "status": "submitted"
  }'

5. Check the decision data and/or session related info from the decision webhook and/or query the data from the GET sessions/{sessionId}/decision[↗] endpoint.

→ Solution-specific overview of what to expect is provided below in Find decision and/or session related info section.

Find decision and/or session related info

You can get the data from three sources:

• Receive the decision webhook

• Query the results via GET sessions/{sessionId}/decision[↗]

• View the session in Veriff Customer Portal

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

Below are a sample and an explanation of a decision webhook payload for a minimal CURP Database Verification.
Depending on your solution, the payload may contain additional parameters. To find more info about it, see the decision webhook documentation.

Sample request

{
  "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.

          • 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

Below are a sample and an explanation of a GET /decision API call payload for a minimal CURP Database Verification.
Depending on your solution, the payload may contain additional parameters. To find more info about it, see the GET sessions/{sessionId}/decision[↗] documentation.

Sample response

{
  "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.

          • 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.

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)

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

Changelog