---
title: Cómo agregar una nueva capacidad (API)
description: Para clientes ya integrados vía API (POST /v1/process) con Clasificación de Riesgo de Fraude (Trust Network) que están agregando Verificación de Identidad a su contrato.
canonical: https://developer.unico.io/es/dual-api/developers/api-reference/api/upgrade-guide
locale: es
generated_by: markdown-export
---

:::info
Esta guía es para clientes que ya integraron vía **API** (`POST /processes/v1`) con Clasificación de Riesgo de Fraude (Trust Network) y están agregando Verificación de Identidad a su contrato.
:::

## Agregar Verificación de Identidad

Esta guía explica la evolución del motor de decisión para reforzar tus procesos de validación de identidad.

:::warning[Requisito técnico]
A diferencia de otras integraciones, para habilitar esta capacidad **es imprescindible actualizar tu API Key**. Sin este cambio, no vas a poder recibir las nuevas respuestas de validación de identidad — tu contacto de Unico te las compartirá.
:::

### El gran cambio: Verificación de Identidad

La principal mejora es la capacidad de validar la identidad del titular (además de las respuestas de fraude). Ahora, el sistema verifica si la persona que realiza el proceso es efectivamente la dueña del documento proporcionado.

Es vital que tu equipo entienda y mapee correctamente la nueva interpretación de las respuestas antes de que la capacidad se active, para no impactar la operación.

### Tabla comparativa de resultados

| Resultado (solo Trust) | Resultado (Trust + IDUnico) | Significado y acción recomendada |
|---|---|---|
| N/A | `APPROVED` | **Nuevo (estado ideal).** El usuario es el titular del ID y no hay evidencia de fraude. |
| `INCONCLUSIVE` | `INCONCLUSIVE` | **Cambio de matiz.** El usuario es real y no hay evidencia de fraude, pero no hay certeza de que sea el dueño del ID. |
| `REPROVED` | `REPROVED` | **Rechazo recomendado.** Indicadores de fraude, o el sistema confirmó que el usuario no es el dueño del ID. |
| `HIGH_RISK` | `HIGH_RISK` | Al menos una evidencia fuerte de fraude. El cliente decide la acción. |
| `CRITICAL_RISK` | `CRITICAL_RISK` | Al menos dos evidencias críticas de fraude. Rechazo recomendado. |

### Cambios clave en la nomenclatura

Asegurate de que tu sistema esté preparado para mapear estos tres cambios fundamentales en tu flujo de aprobación:

1. **La llegada de `APPROVED`** — es ahora el estado "ideal". Si recibís este código, tenés certeza total de identidad y seguridad del proceso.
2. **El nuevo matiz de `INCONCLUSIVE`** — antes era tu luz verde principal. Ahora significa que la persona es "real" y no hay fraude evidente, pero el sistema no pudo vincularla con total certeza a la identidad del ID.
3. **La severidad de `REPROVED`** — además de los indicadores de fraude multifactor, este estado ahora también incluye los casos donde el usuario está suplantando la identidad del titular del ID.