--- title: "INE Database Verification" slug: "ine-database-verification" description: "INE Database Verification offers real-time validation of Mexican voter IDs against the official INE database, ensuring identity and voting eligibility compliance." updated: 2026-04-17T07:48:36Z published: 2026-04-17T07:48:36Z --- > ## 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. # INE Database Verification | Available via API | Available via SDK | Needs configuration on Veriff’s side | Needs a separate integration | Needs a separate webhook | | --- | --- | --- | --- | --- | | ✅ | ✅ | ✅ | ❌/✅* | ❌ | I**NE Database Verification**is a Mexican voter ID verification solution that **validates** **government-issued INE (*Instituto Nacional Electoral*) cards** against the **official *INE Lista Nominal* database**. The INE is a national electoral ID card that serves both as proof of identity and as a voting credential. The solution performs real-time validation of voter registration status, ID validity, and electoral eligibility to ensure accurate identity verification for Mexican residents and compliance with local financial regulations. ***INE Database Verification** can be: - add-on to your document + selfie IDV or document-only IDV, or - used separately as a stand-alone check. In this case the whole flow is done over the API. **INE Database Verification**is available via API and native SDKs. 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 session info 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] > **Note**: Contact your Solutions Engineer for initial configuration of this feature. --- ## Prerequisites - You have an [integration set up](/v1/docs/how-to-create-an-integration) with Veriff - The **INE database check is configured** for that integration **by your Solutions Engineer** - You have configured the [decision webhook](/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 INE credential data** - 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 ### Key terminology | Term | Description | | --- | --- | | INE | *Instituto Nacional Electoral* (National Electoral Institute). The INE issues ID cards that contain a voter identification number. These cards come in different types ranging from D to H, with each type requiring different input parameters for verification. | | CIC | *Código* *de Identificación de la Credencial* (Credential Identification Code). This is the main identification number on the INE card, required for all card types. | | OCR | Optical Character Recognition code found on type D INE cards. | | *Identificador Ciudadano* | Citizen identifier code found on type E, F, G, and H INE cards. | --- ## Flow overview The flow is a bit different, depending on the method (SKD or API) you are using to verify your end-users with Veriff. ### End-user data sources and requirements The INE Database Verification requires **end-user’s credential data to be provided via initData** or **document extraction**. The specific fields required depend on the INE card type (D through H). **Required parameters** | Card Type | Required Fields | Parameters in POST /session payload | | --- | --- | --- | | Type D | CIC + OCR (`mxIfe`) | `verification.document.number` + `verification.document.documentNumberIdentifiers.mxIfe` | | Type E | CIC + *Identificador Ciudadano* (`mxIne`) | `verification.document.number` + `verification.document.documentNumberIdentifiers.mxIne` | | Type F | CIC + *Identificador Ciudadano* (`mxIne`) | `verification.document.number` + `verification.document.documentNumberIdentifiers.mxIne` | | Type G | CIC + *Identificador Ciudadano* (`mxIne`) | `verification.document.number` + `verification.document.documentNumberIdentifiers.mxIne` | | Type H | CIC + *Identificador Ciudadano* (`mxIne`) | `verification.document.number` + `verification.document.documentNumberIdentifiers.mxIne` | The system accepts either `mxIfe` or `mxIne` parameters, not both at the same time. ### Use via SDKs 1. Generate a verification session using the API keys and the `baseURL` of your INE Database Verification integration (see the gration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these) 2. Capture end-user's document with Veriff's SDKs: - Send the end-user through the verification flow to capture the images (using the preferred Veriff SDK). The SDK automatically extracts the required INE identifiers - You need the session URL generated in step 1 to use the SDKs (found in response payload as `verification.url`) 3. Session will be submitted automatically once the end-user takes and submits necessary images 4. Receive the results from Veriff via decision webhook or poll them via [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] endpoint ### Use via API #### Stand-alone INE verification Use when you only need to verify an INE credential without collecting document (and selfie) images. 1. Generate a verification session using the API keys and the `baseURL` of your INE Database Verification integration gration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these) - Make sure to pass the mandatory `document.number` parameter with the CIC value - Include either `document.documentNumberIdentifiers.mxIfe` OR `document.documentNumber_identifiers.mxIne` depending on the [end-user data sources and requirements](/v1/docs/ine-database-verification#enduser-data-sources-and-requirements) ```json {  "verification": {    "callback": "https://yourwebsite.com/webhook",    "document": {      "number": "123456789M00000000",      "documentNumberIdentifiers": {        "mxIne": "1234567890123"      }    }  } } ``` 1. Patch session status to `submitted` status using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call ```bash 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"}' ``` 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. #### INE with document verification 1. Generate a verification session using the API keys and the `baseURL` of your INE Database Verification integration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these) - Make sure to pass the mandatory `document.number` parameter with the CIC value. - Include either `document.documentNumberIdentifiers.mxIfe` OR `document.documentNumber_identifiers.mxIne` depending on the [end-user data sources and requirements](/v1/docs/ine-database-verification#enduser-data-sources-and-requirements) - 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": {    "document": {      "number": "123456789M00000000",      "documentNumberIdentifiers": {        "mxIne": "1234567890123"      }    },    "endUserId": "f7a8d3e2-9c5b-4e16-b8f1-3d9a2e7c8f45"  } }' ``` ```json {  "verification": {    "document": {      "number": "123456789M00000000",      "documentNumberIdentifiers": {        "mxIne": "1234567890123"      }    },    "endUserId": "f7a8d3e2-9c5b-4e16-b8f1-3d9a2e7c8f45"  } } ``` 1. Use your image-capturing method, or prepare previously collected end-user document image(s). 2. 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' \  -F 'image=@/path/to/ine-document.jpg' \  -F 'data={"image":{"context":"document-front","timestamp":"2025-10-01T10:30:00Z"}}' ``` ```json {  "image": {    "context": "document-front",    "timestamp": "2025-10-01T10:30:00Z"  } } ``` 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"}' ``` ```json {  "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/ine-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/ine-database-verification#webhook-payload)) - Query the results via GET /sessions/{sessionId}/decision ([example below](/v1/docs/ine-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 INE validation results are returned in `additionalVerifiedData.officialDatabaseVerification.ine` within the webhook payload. The verification performs three checks: 1. **Processing status** - Indicates whether the INE verification request was successfully processed 2. **INE card validity** - Confirms the INE credential exists and the data matches the official registry 3. **Voting eligibility** - Verifies if the credential holder has active voting rights (not suspended or revoked) 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 credential - `skipped` - The check was not executed ### Webhook payload > [!NOTE] > Below are a sample and an explanation of a **decision webhook payload for a minimal INE Database Verification**. Depending on your solution, the payload may contain additional parameters. To find more info about it, 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": "f7a8d3e2-9c5b-4e16-b8f1-3d9a2e7c8f45",    "status": "approved",    "additionalVerifiedData": {      "officialDatabaseVerification": {        "ine": {          "matchData": {            "dateOfBirth": "MATCH",            "fullName": "MATCH",            "gender": "NO_INPUT"          },          "validations": {            "processing": {              "result": "success",              "reasons": null            },            "ineCardIsValid": {              "result": "success",              "reasons": null            },            "ineIsValidForVoting": {              "result": "success",              "reasons": null            },            "matching": {                "result": "sucess"            }          },          "registryResponse": {            "electorKey": "GOMZJN89041509H300",            "issueNumber": "3",            "registrationYear": "2010",            "issueYear": "2018",            "validity": "31 de diciembre de 2028",            "ocr": "0876543210987",            "cic": "IDMEX2023456789012",            "federalDistrict": "4"          }        }      }    },    "attemptId": "96d8c583-0855-43c2-b549-bf8824465835"  },  "technicalData": {    "ip": null  } } ``` #### Request properties explained - `status`: `string` Status of the response - `verification`: `object` Verification request decision object. `null` if decision is not available yet - `id`: `string` UUID v4 which identifies the verification session - `attemptId`: `string` UUID v4 of the attempt which received a status - `vendorData`: `string` | `null` The unique identifier that you created for your end-user. `null` if not specified - `endUserId`: `string` | `null` The UUID that you created for your end-user. `null` if not specified - `status`: `string` Verification status, one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned` - `decisionTime`: `string` | `null` Timestamp of the decision, represented as UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset (ISO 8601) - `acceptanceTime`: `string` Timestamp of the session generation, represented as UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset (ISO 8601) - `code`: `number` Verification code indicating the reason for the decision - `additionalVerifiedData`: `object` Contains the results of all validations - `officialDatabaseVerification`: `object` Contains the results of the database verification - `ine`: `object` Contains INE verification results - `validations`: `object` Contains validation check 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/ine-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 - `processing`: `object` Processing validation result - `result`: `string` One of `success`, `failure` (request processing encountered an error, e.g., system error, communication issue, provider unavailable), `not_applicable` (processing check was not configured), `skipped` - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `ineCardIsValid`: `object` Confirms that the INE credential exists and data matches - `result`: `string` One of `success`, `failure` (credential is invalid, the data does not match, or the credential does not exist), `not_applicable` (processing check was not configured), `skipped` - `reasons`: `array` Additional information about the validation result. Not sent if `result`: `success`. - `ineIsValidForVoting`: `object` Verifies active voting rights - `result`: `string` One of `success`, `failure` (voting rights have been suspended or revoked, though the credential may still be valid as an ID), `not_applicable` (processing check was not configured), `skipped` - `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 (`ine.matchData` parameter is included in the payload) - `result`: `string` Always `success`, irrespective of `matchData` results - `registryResponse`: `object` Detailed information from the Mexican electoral registry - `electorKey`: `string` Voter key (*Clave de Elector*) assigned to the credential holder - `issueNumber`: `string` The issue/emission number of the credential (1-9 indicating how many times the credential has been reissued) - `registrationYear`: `string` Year the person was registered in the electoral system - `issueYear`: `string` Year the current credential was issued - `validity`: `string` Expiration date of the credential (format: *DD de MMMM de YYYY* in Spanish) - `ocr`: `string` OCR (Optical Character Recognition) code from the credential - `cic`: `string` CIC (*Código de Identificación de la Credencial*) aka credential identification code - `federalDistrict`: `string` Federal electoral district number - `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 INE Database Verification**. Depending on your solution, 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": "f7a8d3e2-9c5b-4e16-b8f1-3d9a2e7c8f45",    "status": "approved",    "additionalVerifiedData": {      "officialDatabaseVerification": {        "ine": {          "matchData": {            "dateOfBirth": "MATCH",            "fullName": "MATCH",            "gender": "NO_INPUT"          },          "validations": {            "processing": {              "result": "success",              "reasons": null            },            "ineCardIsValid": {              "result": "success",              "reasons": null            },            "ineIsValidForVoting": {              "result": "success",              "reasons": null            },            "matching": {                "result": "sucess"            }          },          "registryResponse": {            "electorKey": "GOMZJN89041509H300",            "issueNumber": "3",            "registrationYear": "2010",            "issueYear": "2018",            "validity": "31 de diciembre de 2028",            "ocr": "0876543210987",            "cic": "IDMEX2023456789012",            "federalDistrict": "4"          }        }      }    },    "attemptId": "96d8c583-0855-43c2-b549-bf8824465835"  },  "technicalData": {    "ip": null  } } ``` #### Response properties explained - `status`: `string` Status of the response - `verification`: `object` Verification request decision object. `null` if decision is not available yet - `id`: `string` UUID v4 which identifies the verification session - `attemptId`: `string` UUID v4 of the attempt which received a status - `vendorData`: `string` | `null` The unique identifier that you created for your end-user. `null` if not specified - `endUserId`: `string` | `null` The UUID that you created for your end-user. `null` if not specified - `status`: `string` Verification status, one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned` - `decisionTime`: `string` | `null` Timestamp of the decision, represented as UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset (ISO 8601) - `acceptanceTime`: `string` Timestamp of the session generation, represented as UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset (ISO 8601) - `code`: `number` Verification code indicating the reason for the decision - `additionalVerifiedData`: `object` Contains the results of all validations - `officialDatabaseVerification`: `object` Contains the results of the database verification - `ine`: `object` Contains INE verification results - `validations`: `object` Contains validation check 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/ine-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 - `processing`: `object` Processing validation result - `result`: `string` One of `success`, `failure` (request processing encountered an error, e.g., system error, communication issue, provider unavailable), `not_applicable` (processing check was not configured), `skipped` - `reasons`: `null` | `array` Additional information about the validation result - `ineCardIsValid`: `object` Confirms that the INE credential exists and data matches - `result`: `string` One of `success`, `failure` (credential is invalid, the data does not match, or the credential does not exist), `not_applicable` (processing check was not configured), `skipped` - `reasons`: `null` | `array` Additional information about the validation result - `ineIsValidForVoting`: `object` Verifies active voting rights - `result`: `string` One of `success`, `failure` (voting rights have been suspended or revoked, though the credential may still be valid as an ID), `not_applicable` (processing check was not configured), `skipped` - `reasons`: `null` | `array` Additional information about the validation result - `matching`: `object` Optional, only available when the input data matching validation was enabled for the integration (`ine.matchData` parameter is included in the payload) - `result`: `string` Always `success`, irrespective of `matchData` results - `registryResponse`: `object` Detailed information from the Mexican electoral registry - `electorKey`: `string` Voter key (*Clave de Elector*) assigned to the credential holder - `issueNumber`: `string` The issue/emission number of the credential (1-9 indicating how many times the credential has been reissued) - `registrationYear`: `string` Year the person was registered in the electoral system - `issueYear`: `string` Year the current credential was issued - `validity`: `string` Expiration date of the credential (format: *DD de MMMM de YYYY* in Spanish) - `ocr`: `string` OCR (Optical Character Recognition) code from the credential - `cic`: `string` CIC (*Código de Identificación de la Credencial*) aka credential identification code - `federalDistrict`: `string` Federal electoral district number - `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 INE 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) --- ## INE validation result scenarios Below are the most common scenarios of INE Database Verification validation results. | Scenario | `officialDatabaseVerification.ine.validations` object | Error handling | | --- | --- | --- | | The INE/IFE is valid as an ID and valid for voting purposes | - `ineCardIsValid`: `success` - `ineIsValidForVoting`: `success` - `processing`: `success` | - N/A, checks have passed and the session is `approved` | | The INE/IFE is invalid due to incorrect or non-existent data | - `ineCardIsValid`: `failure` - `ineIsValidForVoting`: `not_applicable` - `processing`: `success` | - Verify the CIC was entered correctly - Confirm the correct identifier (`mxIfe` for type D, `mxIne` for type E-H) is provided - Ensure all identifiers are from the same credential - Request the user to verify their data | | The INE/IFE is invalid as an ID and invalid for voting purposes | - `ineCardIsValid`: `failure` - `ineIsValidForVoting`: `failure` - `processing`: `success` | - For voting-specific applications, this should result in a decline - For identification purposes, this should result in a decline | | The INE/IFE is valid as an ID but invalid for voting purposes | - `ineCardIsValid`: `success` - `ineIsValidForVoting`: `failure` - `processing`: `success` | - This is not necessarily an error - the credential is still valid for identification - Inform the user their credential is valid but voting rights may be suspended - For voting-specific applications, this should result in a decline - For identification purposes, the card may still be accepted | | Error in the data sent in the request | - `ineCardIsValid`: `failure` - `ineIsValidForVoting`: `not_applicable` - `processing`: `success` | - Check the session payload for errors | | Invalid CIC format Invalid OCR format Invalid elector key format Invalid issue number format | - `ineCardIsValid`: `failure` - `ineIsValidForVoting`: `not_applicable` - `processing`: `success` | - Request the user to verify their data - Check the relevant parameter’s format | | The individual's voting rights have been suspended by court order; the credential is only valid as an ID | - `ineCardIsValid`: `success` - `ineIsValidForVoting`: `failure` - `processing`: `success` | - This is not necessarily an error - the credential is still valid for identification - Inform the user their credential is valid but voting rights may be suspended - For voting-specific applications, this should result in a decline - For identification purposes, the card may still be accepted | | The OCR entered does not match the one in the INE database | - `ineCardIsValid`: `failure` - `ineIsValidForVoting`: `not_applicable` - `processing`: `success` | - Verify the OCR was entered correctly | | Provider unavailable, connection errors, or processing failures | - `ineCardIsValid`: `not_applicable` - `ineIsValidForVoting`: `not_applicable` - `processing`: `failure` | - Check credential data format - Verify API credentials - Contact Veriff support if issue persists | --- ## Additional information ### Best practices 1. **Provide only one identifier**: Include either `mxIfe` or `mxIne` based on [card type](/v1/docs/ine-database-verification#enduser-data-sources-and-requirements) to avoid conflicts 2. **Format validation**: Validate credential format on your side before submitting: - CIC: 18 characters (alphanumeric) - OCR (`mxIfe`): 13 digits - *Identificador Ciudadano* (`mxIne`): Variable length alphanumeric 3. **Error handling**: Implement proper error handling for all possible [validation results](/v1/docs/ine-database-verification#ine-validation-result-scenarios) 4. **Data privacy**: Handle registry response data according to Mexican data privacy laws (LFPDPPP) 5. **Webhook security**: Secure your webhook endpoint and verify request signatures 6. **User experience**: - Provide clear feedback about validation results - For voting rights issues, explain that the card may still be valid for ID purposes - Guide users to correct common input errors 7. **Card type awareness**: Inform users which identifiers are needed based on their card type 8. **Validity period**: Check the validity field in the registry response to ensure credential has not expired 9. **Dual-purpose consideration**: Remember that INE credentials serve both as ID and voting credentials - configure validations based on your use case --- ## FAQ #### What are the use cases for registry response data? The `registryResponse` object contains complete information retrieved from the Mexican electoral database for: - Identity matching - Compare registry data with user-provided or document-extracted information - Age verification - Calculate age based on registration year - Additional verification - Cross-reference elector key, issue numbers, and districts - Record keeping - Store official government data for compliance purposes - Voting eligibility confirmation - Verify credential validity period and voting rights status #### What are common use cases for INE Database Verification? **INE verification with document capture** Combine INE verification with document capture for enhanced verification: 1. Create session with INE data in `initData` 2. Capture document images through SDK (document extraction will populate fields automatically) 3. Receive combined verification results with both document verification and database validation **Voting eligibility check** Specifically verify if someone can vote: - Submit INE credential data - Check the `ineIsValidForVoting` validation result - Use for voter registration, polling applications, or civic participation platforms **Identity verification only** Verify identity without concern for voting rights: - Submit INE credential data - Focus on the `ineCardIsValid` validation result - Use for KYC, account creation, or general identity verification #### Can I integrate this solution with CURP Database Verification? INE and [CURP verifications](/v1/docs/curp-database-verification) can be used together for comprehensive Mexican identity verification: - **Use CURP for identity data verification**: Validates the person's demographic information (name, date of birth, gender, place of birth) - **Use INE for credential verification**: Validates the physical credential and voting rights - **Cross-reference both**: The electoral registry may contain CURP information that can be compared with CURP verification results This dual-verification approach provides the highest level of confidence in Mexican identity verification. --- ## Changelog | Date | Description | | --- | --- | | Apr 17, 2026 | `MEX` prefix removed from `mxIne` placeholder in session creation sample payloads | | Dec 12, 2025 | Broken links fixed, `x-hmac-signature` restored to request examples | | Nov 27, 2025 | Intro section updated | | Nov 19, 2025 | `ine.matchData` , `validations.matching` and [Note about matchData](/v1/docs/ine-database-verification#note-about-matchdata) added to webhook and API payloads sections | | Nov 17, 2025 | API flow steps formatting 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. This where the end-user is directed to go through the verification flow, and it is **unique for each verification session**. It is a combination of the `base URL` and the `sessionToken`, created as soon as a verification session is created. You can find its value in the response payload of your POST /sessions call, as `verification.url`. The data that you send when you make an API request, or that you receive when you get a response.