Evento de identidad acreditada

TL;DR - Acceso Rápido

• kyc.identity.level_changed llega cuando la revisión de identidad de la persona de tu transacción termina aprobada.
• data.transaction_status te dice qué hacer: con pending puedes mandar a la persona al mismo enlace de autorización, con authorized la transacción ya quedó autorizada y con closed abres una transacción nueva.
• data.connection_at_approval dice si había una conexión viva al aprobar, no si la persona está mirando.

Cuando una persona intenta autorizar con PIN-RUT y todavía no tiene su identidad acreditada, la plataforma la guía por el proceso de acreditación. La mayoría de las veces termina en minutos y la transacción sigue su curso normal, sin que tengas que hacer nada.

Pero no siempre. Un caso puede quedar en revisión de una persona de nuestro equipo y resolverse horas o días después. Para entonces la persona puede seguir con la pantalla abierta o haberse ido hace rato, y la transacción puede seguir viva o ya no. Este evento te avisa que la revisión se aprobó y te dice en qué quedó tu transacción, para que decidas qué hacer.

---

Cuándo se despacha

Situación	¿Llega el evento?
La revisión de identidad de la persona de tu transacción termina aprobada	Sí
La acreditación se resuelve sola, con la persona en el flujo	No — la persona sigue en la misma pantalla y autoriza ahí mismo
La revisión termina sin aprobarse	No
La identidad aprobada no es la del RUT de tu transacción	No

Sólo informa una aprobación

No hay evento para una revisión que no se aprueba, y no lo va a haber: comunicar que una persona no quedó acreditada diría por qué, y eso es información de ella, no tuya. En ese caso te enteras cuando la transacción vence.

---

Quién lo recibe

Sólo la integración de la transacción cuya persona pasó por la revisión. Si tienes varias integraciones, el aviso llega a la que abrió la transacción, no a todas.

El destino se resuelve igual que el resto de tus webhooks de PIN-RUT: el callback_url de esa transacción y, si no lo declaraste, la URL de webhooks configurada para tu cuenta.

La lista de eventos habilitados

Si tu cuenta tiene una lista de eventos habilitados no vacía y usas PIN-RUT con acreditación de identidad —con PIN o con cara—, incluye kyc.identity.level_changed: sin él no recibes este aviso. Una lista vacía no filtra nada.

---

Payload

{
  "event": "kyc.identity.level_changed",
  "timestamp": "2026-09-14T18:40:12.051Z",
  "data": {
    "transaction_id": "8b5f2c1e-4d7a-4c3b-9e21-6f0a1d2b3c4d",
    "transaction_created_at": "2026-09-14T13:02:47.118Z",
    "approved_at": "2026-09-14T18:40:11.964Z",
    "transaction_status": "pending",
    "connection_at_approval": "none",
    "state": "orden-4581",
    "authentication_method": "pin"
  }
}

Campo	Tipo	Descripción
event	string	Siempre kyc.identity.level_changed
timestamp	string (ISO 8601)	Instante en que se despachó el aviso
data.transaction_id	string (UUID)	La transacción que creaste y cuya persona pasó por la revisión
data.transaction_created_at	string (ISO 8601)	Cuándo creaste esa transacción
data.approved_at	string (ISO 8601)	Cuándo se aprobó la revisión
data.transaction_status	string	En qué quedó la transacción al aprobarse: pending, authorized o closed
data.connection_at_approval	string	Si había una conexión viva al aprobar: open, none o unknown
data.state	string o null	El valor opaco que enviaste al crear la transacción
data.authentication_method	string	La modalidad que pediste: pin o face

Nada de la persona

El payload no lleva RUT, ni nombres, ni identificadores de la persona, ni qué se revisó, ni por qué había quedado en revisión, ni la fecha de expiración de la transacción. Eso no es una limitación temporal: es el contrato.

---

Qué hacer al recibirlo

Según transaction_status

Valor	Qué significa	Qué puedes hacer
pending	La transacción sigue pendiente y no ha vencido	Mandar a la persona al mismo enlace de autorización ahora: el plazo de la transacción sigue corriendo
authorized	La transacción ya está autorizada	Nada más: la autorización te llega por su propio evento, pin.transaction.authorized
closed	La transacción ya no se puede autorizar: venció, se canceló o falló	Crear una transacción nueva sobre el mismo RUT. La persona ya tiene su identidad acreditada

transaction_status se informa como estado y nunca como un plazo: el tiempo que le queda a una transacción pendiente no forma parte del aviso.

Qué significa connection_at_approval

Valor	Qué significa
open	Al aprobarse, la persona tenía abierta la pantalla de espera, en su celular o en su computador
none	Al aprobarse, no había ninguna conexión viva
unknown	No se pudo saber

«Había una conexión viva» no es «la persona está mirando»

Un celular con la pantalla bloqueada o una red cortada terminan la conexión aunque la persona vaya a volver en un minuto. Con pending y none igual puedes mandarla al enlace de autorización.

Cuánto tiempo pasó

La diferencia entre data.transaction_created_at y data.approved_at es cuánto tardó la revisión desde que creaste la transacción. Te sirve para decidir si todavía tiene sentido contactar a la persona.

Cómo saber a qué persona corresponde

El evento no trae el RUT. Guarda el transaction_id de cada transacción junto con el RUT de tu lado: cuando llegue el aviso, la correlación la haces con tus propios datos. No existe ningún endpoint para consultar el estado de acreditación de un RUT, y su ausencia es deliberada — sería un padrón de quién está verificado y quién no.

---

Seguridad y reintentos

Se entrega con la misma firma HMAC y la misma política de reintentos que el resto de los webhooks de la plataforma. Si una entrega se reintenta, el aviso trae el mismo transaction_id: procésalo de forma idempotente. Ver Webhooks.

---

Relacionado

• PIN-RUT — el flujo completo, las dos modalidades y el cargo de la acreditación
• Webhooks — configuración, firma HMAC y reintentos