---
title: "Combined INE+CURP database verification guide | Veriff.com"
slug: "combined-inecurp-database-verification-guide"
description: "Learn how to verify identities in Mexico using the combined INE and CURP database check, ensuring compliance for businesses with essential verification checks."
tags: ["CURP Database", "Identity Verification", "INE Verification", "Mexican registries"]
updated: 2025-03-07T13:20:53Z
published: 2025-03-07T13:20:53Z
---

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

# Combined INE+CURP database verification guide

This guide gives an overview of the **verification check of the Mexican INE and CURP databases**. Businesses operating in Mexico are obliged to verify their users’ identity using database verification checks as part of the identity verification process.

It is available via API, web flow, and native SDKs.

The CURP (Unique Key of Population Registry) is the name of the population number/certificate in Mexico.

INE (Institutio Nacional Electoral - Mexican Electoral Registry) is the organization that issues the voter ID cards and maintains the voters registry.

---

## Prerequisites

- You have an [**integration set up**](/v1/docs/how-to-create-an-integration)**with Veriff**
- The **check is configured** for that integration **by your Solutions Engineer**
- A verification session generated for the end-user
- The [INE+CURP registry validation webhook](/v1/docs/inecurp-webhook) has been set up

> [!NOTE]
> Contact your **solutions engineer** for info and configuration.

---

## Flow overview

The flow is a bit different, depending on the method you are using to verify your end-users with Veriff.

### Use via SDK

1. Generate a verification session using the `API keys` and the `baseURL` of the integration used for this solution (see the <meta charset="utf-8">[API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
2. Capture end-user’s document and selfie images with Veriff’s SDKs
  1. Send the end-user through the verification flow to capture the images (using the preferred [Veriff SDK](/v1/docs/sdk-guide))
  2. 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 [INE+CURP webhook](/v1/docs/inecurp-webhook)

### Use via API

1. Generate a verification session using the a `API keys` and the `baseURL` of the integration used for this solution (see the <meta charset="utf-8">[API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
  1. Veriff strongly recommends you create and send the `endUserId` or `vendorData`
  2. Veriff strongly recommends you collect and send additional session/device data via <meta charset="utf-8">[POST sessions/{sessionid}/collected-data](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidcollected-data-1)[↗] for improved fraud detection
2. Use your image-capturing method, or prepare previously collected end-user selfie and document images
3. Upload the end-user's media via <meta charset="utf-8">[POST /sessions/{sessionId}/media](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidmedia-3)[↗] call
  1. Specify the `image.context` as appropriate for the image (see [Context types (image, video)](/v1/docs/context-types-image-video-1) for more info about image context types)
4. Patch session status to `submitted` status using <meta charset="utf-8">[PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call
5. Check the decision data and/or session related info from the [INE+CURP webhook](/v1/docs/inecurp-webhook) and/or query the data from the endpoint <meta charset="utf-8">[GET /sessions/{sessionId}/decision/combined-ine-curp-registry](https://devdocs.veriff.com/apidocs/v1sessionsiddecisioncombined-ine-curp-registry-1)[↗]

---

## Find decision and/or session related info

### Webhook payload

First and foremost, you should check the **INE+CURP registry validation webhook**payload.

*→ See the*[*INE+CURP webhook*](/v1/docs/inecurp-webhook)*article for detailed info*

### API call

Second source is the <meta charset="utf-8">[GET /sessions/{sessionId}/decision/combined-ine-curp-registry](https://devdocs.veriff.com/apidocs/v1sessionsiddecisioncombined-ine-curp-registry-1)[↗] endpoint, see the documentation for more info.

> [!NOTE]
> Make sure to add the mandatory query parameter `version=1.0.0` to the API URL: `GET sessions/{sessionId}/decision/combined-ine-curp-registry?version=1.0.0`

### Veriff Customer Portal

You can find the verification session related info in the Veriff Customer Portal, under the **Webhooks** tab.

<meta charset="utf-8">

→ *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*

---

### Full forms of the `statusCurp` acronyms

- Active CURP: `AN` (Alta Normal), `AH` (Alta con Homonimia), `CRA CU` (CURP Reactivada), `RCN` (Registro de Cambio no Afectando a CURP), `RCC` (Registro de Cambio Afectando a CURP)
- For inactive CURP: `BD` (Baja por Defuncion), `BDA` (Baja por Duplicidad), `BCC` (Baja por Cambio en CURP), `BCN` (Baja no Afectando a CURP)

---

## Status and reason codes

For an `approved` session, see the `verification.code` and `verification.status` parameters.

If the session was `declined` or `resubmission_requested`, you can find additional information by checking the `verification.status`, `verification.code`, `verification.reason` and `verification.reasonCode` data objects.

For more info about the codes you are seeing, refer to:

- [Verification session status codes (table)](/v1/docs/verification-session-status-codes-table)
- [Verification session decision codes (table)](/v1/docs/verification-session-decision-codes-table)
- [Granular reason codes (table)](/v1/docs/granular-reason-codes)

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.

**User of Veriff customer's solution**, the person who goes through the verification flow (aka "end-user flow").

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.

## Related

- [Getting Started](/getting-started.md)
- [Integrations](/how-to-create-an-integration.md)
- [Create verification session](/how-to-generate-sessions-manually.md)
- [INE+CURP webhook](/inecurp-webhook.md)
- [Codes](/codes.md)