> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gu1.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Registro de Cambios

> Últimas actualizaciones y mejoras en la documentación de gu1 — cubriendo nuevos endpoints, funciones del panel y correcciones, con ejemplos para changelog.

***

***

***

***

<Update label="2026-07-31" description="Filtrar transacciones por la fecha de su última evaluación de reglas" tags={["Transacciones", "Reglas"]}>
  ## Filtro por última evaluación de reglas

  **`GET /transactions`** ahora acepta los filtros ISO inclusivos opcionales
  `lastRiskEvaluationFrom` y `lastRiskEvaluationTo`. Pueden combinarse para seleccionar
  transacciones cuya última evaluación exitosa de reglas esté dentro de un rango.
  Las transacciones evaluadas antes de que existiera este campo se resuelven desde su
  historial de análisis de riesgo, y el listado ahora devuelve `lastRiskEvaluationAt`.

  Ver [Listar transacciones](/es/api-reference/transactions/list).
</Update>

<Update label="2026-07-31" description="Los webhooks legacy de entidades ahora incluyen score y documento" tags={["Webhooks", "Entidades"]}>
  ## Campos adicionales en webhooks legacy planos de entidades

  Los payloads legacy planos de webhooks de entidades ahora incluyen los campos aditivos
  `riskScore` y `documentNumber`. Los valores y mapeos de estados existentes no cambian.

  Ver [Eventos de webhook de entidades](/es/webhooks/events/entity-events).
</Update>

<Update label="2026-07-31" description="Descargar qué transacciones se omitieron por duplicado" tags={["Transacciones", "Batch"]}>
  ## Reporte de filas omitidas en batch de transacciones

  Nuevo endpoint **`GET /batch-import/transaction-jobs/{jobId}/skips.csv`**: lista las transacciones que el batch no insertó porque el `externalId` ya existía (columnas `external_id,reason`). Hasta ahora `skipped` era solo un contador, y una recarga de duplicados parecía un fallo silencioso.

  * Disponible para jobs corridos con el default `skipDuplicates=true`; con `skipDuplicates=false` los duplicados los resuelve la base de datos y solo se cuentan, así que el endpoint devuelve `SKIPS_NOT_AVAILABLE`.
  * Los jobs terminados antes de este release no tienen reporte guardado (`SKIPS_NOT_AVAILABLE`).
  * También disponible como botón de descarga en el historial de importaciones.

  Ver [Fallos batch de transacciones](/es/api-reference/bulk-imports/get-transaction-batch-failures).
</Update>

<Update label="2026-07-24" description="Bulk: relaciones declarativas aunque la entidad ya exista" tags={["Entidades", "Batch"]}>
  ## Relaciones declarativas con `tax_id` duplicado (bulk)

  En importación masiva **manual**, si el `tax_id` de la fila ya existe y se omite la creación, Gu1 **igual aplica** las `relationships` / columnas CSV `related_*` de esa fila (igual que en create **automático**). Si el vínculo (mismo source → target + tipo) ya existe, se omite de forma idempotente.

  Ver [Importar entidades (bulk)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-07-23" description="Relaciones declarativas en create + bulk de entidades" tags={["Entidades", "API", "Batch"]}>
  ## Vínculos a entidades existentes en create e importación masiva

  Podés declarar relaciones a entidades **ya existentes** (por `relatedEntityId` / `relatedTaxId` / `relatedExternalId` + `relationshipType` + `role`) sin depender del `depth` de enrichment:

  * **`POST /entities`** y **`POST /entities/automatic`**: body opcional `relationships[]` (máx. 10).
  * **Bulk CSV plataforma**: columnas `related_tax_id` / `related_external_id` / `related_entity_id`, `relationship_type`, `relationship_role`, `relationship_as_source` (una relación por fila).
  * Si la contraparte no existe → **`RELATED_ENTITY_NOT_FOUND`** y la entidad **no** se crea.

  Ver [Crear entidad](/es/api-reference/entities/create), [Crear automáticamente](/es/api-reference/entities/create-automatic) e [Importar entidades (bulk)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-07-23" description="Webhook de seguridad: cambio de acceso a entorno" tags={["Webhooks", "Seguridad", "IAM"]}>
  ## `security.member.environment_changed`

  Cuando un admin actualiza el acceso prod/sandbox de un miembro desde Equipos (roster) en **una** asignación, Gu1 emite un solo webhook en lugar de varios grant/revoke:

  * **Evento:** `security.member.environment_changed`
  * **`context.fromAccess` / `context.toAccess`:** `"both"` | `"production"` | `"sandbox"` | `"none"`
  * **`changes.environmentAccess`:** `{ previous, current }` con los mismos valores

  Los eventos `security.member.environment_granted` / `.environment_revoked` siguen existiendo para flujos de grant/revoke de un solo ambiente.

  Ver [Eventos de webhook de seguridad](/es/webhooks/events/security-events).
</Update>

<Update label="2026-07-22" description="linkEntityStrict + soft-link sin romper defaults de batch" tags={["Transacciones", "API", "Batch"]}>
  ## Link de entidades: soft-link siempre, default estricto de batch sin cambio

  Crear TX / lote **siempre intenta auto-vincular** si hay match (entityId → externalId → taxId).

  * **Default batch (BC):** omitir flags sigue **estricto** — `validateExistingEntity` default **`true`**. Refs sin resolver → **400** (igual que antes).
  * **`linkEntityStrict=true`**: fuerza hard-fail (body o query).
  * **`linkEntityStrict=false`**: fuerza soft-link (no falla si falta), aunque `validateExistingEntity` diga otra cosa.
  * **`validateExistingEntity=false`**: soft-link (y ahora sí vincula si encuentra — antes el soft de batch salteaba el link).

  `POST /transactions` (una TX) mantiene `validateExistingEntity` default **`false`**.

  Ver [Crear lote](/es/api-reference/transactions/create-batch).
</Update>

<Update label="2026-07-13" description="Rename del código de cuota contractual de creación" tags={["API", "Billing"]}>
  ## Código de error: `CREATION_CONTRACT_QUOTA_EXCEEDED`

  Cuando se agota la **cuota contractual de creación** de la organización (entidades, transacciones, eventos de usuario), las APIs de Gu1 responden **`429`** con código **`CREATION_CONTRACT_QUOTA_EXCEEDED`** (antes `CREATION_QUOTA_EXCEEDED`).

  * Mismo status HTTP y shape del payload (`module`, `remainingTotal`, `periodKey`, `requested`).
  * Los fallos de fila en bulk import emiten **`CREATION_CONTRACT_QUOTA_EXCEEDED`**; el código viejo queda como alias deprecado para `failures.csv` históricos.

  Ver [Códigos de fallo de bulk import](/es/api-reference/bulk-imports/batch-import-failure-codes).
</Update>

<Update label="2026-07-10" description="Unicidad de taxId entre person y company" tags={["API", "Entities"]}>
  ## Unicidad de tax ID (por organización)

  Un **`taxId`** activo (normalizado alfanumérico) puede pertenecer a **una sola** entidad por organización, sea `person` o `company`.

  * **Mismo tipo** ya existe → la creación automática **reutiliza** esa entidad (`alreadyExisted`).
  * **Otro tipo** ya tiene el tax ID → **`409`** con código **`DUPLICATE_TAX_ID`** (sin fila nueva).
  * Aplica a create manual, create automatic, PATCH de tax ID y restore de soft-delete.
  * Los duplicados históricos no se borran; los writes conflictivos nuevos se bloquean en app y con un trigger en base de datos.

  Ver [Crear entidad automáticamente](/es/api-reference/entities/create-automatic) y [Crear entidad](/es/api-reference/entities/create).
</Update>

<Update label="2026-07-08" description="Acción addFieldToCustomList en reglas" tags={["API", "Rules"]}>
  ## Nueva acción de regla: `addFieldToCustomList`

  Las reglas de **transacción**, **persona** y **empresa** pueden incluir la acción `addFieldToCustomList`. Al hacer match, el motor extrae uno o más campos del contexto evaluado y los agrega a **listas custom** del tenant (`type: custom`, activas, no globales).

  ```json theme={null}
  {
    "type": "addFieldToCustomList",
    "addFieldToCustomList": {
      "mappings": [
        { "fieldPath": "originTaxId", "listId": "uuid-lista-123" },
        { "fieldPath": "metadata.phone", "listId": "uuid-lista-456" }
      ],
      "reason": "Opcional — motivo en el ítem"
    }
  }
  ```

  Valores vacíos se omiten; duplicados por `primaryValue` se ignoran. Disponible en `POST`/`PUT` de reglas universales y en el Rule Builder.
</Update>

<Update label="2026-07-08" description="Bloqueo en creación por listas" tags={["API", "Entities"]}>
  ## Bloqueo en creación (configuración de análisis de riesgo)

  Las organizaciones pueden configurar **reglas de bloqueo en creación** en **Configuración de la organización → Análisis de riesgo**: un campo de entidad (p. ej. `taxId`) contra una lista custom. Si el valor está en la lista, **se bloquea la creación**: la solicitud falla con **`422`** y código **`ENTITY_CREATION_LIST_BLOCK`** (`details`: `ruleId`, `listId`, `fieldPath`, `scope`, `matchedValue`). El intento bloqueado queda registrado en el log de auditoría como evidencia.

  Aplica a **`POST /entities`**, **`POST /entities/automatic`**, importación masiva, upsert (solo alta) y creación automática desde eventos SDK. Accionistas/UBO en creación automática si el alcance de la regla lo incluye; si se bloquea un accionista, se revierten las entidades creadas en esa corrida automática.
</Update>

<Update label="2026-07-03" description="PATCH /entities/{id}/attributes" tags={["API", "Entities"]}>
  ## Endpoint dedicado para atributos

  **`PATCH /entities/{id}/attributes`** — actualiza solo atributos personalizados sin tocar otros campos.

  * **`mode: merge`** (default) — las claves enviadas pisan o crean; las omitidas **se conservan**
  * **`mode: replace`** — `attributes` del body reemplaza el mapa completo (`{}` borra todo)
  * Buckets anidados por categoría en escritura
  * Dispara webhook **`entity.updated`** y matrices con trigger **`entity_updated`** cuando aplica

  Ver [Actualizar atributos](/es/api-reference/entities/attributes-update).
</Update>

<Update label="2026-07-03" description="Atributos de entidad: almacenamiento tal cual + categorías" tags={["API", "Entities"]}>
  ## Atributos personalizados almacenados tal cual (API)

  **Aditivo.** Los `attributes` se almacenan **exactamente como se envían** en create/update/upsert/importación automática — el input anidado ya no se aplana.

  * **Sin categoría:** valores escalares/array en la raíz (p. ej. `{ "phone": "..." }`) — sin cambios.
  * **Categorizado:** un objeto de primer nivel agrupa sus claves internas bajo esa categoría (p. ej. `{ "contact": { "phone": "..." } }`). La clave del objeto *es* la categoría; en el dashboard se muestra como card de categoría.
  * **Lectura:** `GET` devuelve la misma forma que se escribió (sin aplanar).
  * **Reglas / webhooks:** leen la forma almacenada — `attributes.phone` para plano, `attributes.contact.phone` para anidado. Usá claves de categoría identificador-seguras.

  Ver [Obtener entidad](/es/api-reference/entities/get) y [Actualizar entidad](/es/api-reference/entities/update).
</Update>

<Update label="2026-07-03" description="API activación de país por entidad + webhook" tags={["API", "Webhooks", "Entities"]}>
  ## Activación operativa por país (merchant)

  **Aditivo.** Activar o desactivar países soportados por entidad sin modificar el perfil de la entidad:

  * **`GET /entities/{id}/country-activations`** — lista AR, BR, CL, CO, MX, US; filas ausentes = `deactivated` (opt-in).
  * **`PATCH /entities/{id}/country-activations/{countryCode}`** — body `{ "status": "deactivated" | "activation_requested" | "activation_in_progress" | "activated" }`; requiere `entities:edit`. Transiciones libres. Idempotente si el estado no cambia (sin webhook).
  * **Webhook `entity.country_activation_changed`** — se emite en cada cambio real; incluye `activeCountryCodes`, snapshot `countries` y `timeline` por país; suscribirse en la config de webhooks existente.

  Ver [Listar activaciones](/es/api-reference/entities/country-activations-list), [Actualizar activación](/es/api-reference/entities/country-activations-update) y [Eventos webhook de entidad](/es/webhooks/events/entity-events).
</Update>

<Update label="2026-07-01" description="Bulk import: paridad política de errores en eventos" tags={["API", "Bulk imports"]}>
  ## Import batch de eventos de usuario — política de errores por fila

  **Aditivo.** Los imports CSV de eventos alinean con entidades y transacciones:

  * **`POST /batch-import/import/user-events`** acepta **`batchErrorHandling`**: `continue_collect_errors` (default), `rollback_all` o `stop_keep_success`.
  * Respuestas **`202`** incluyen **`preflightFailures`** cuando filas inválidas se omiten con política continue.
  * **`POST /batch-import/validate-csv`** valida **cada fila** si el target es **`user_event`** (`rowErrors`, `validRowCount`, `invalidRowCount`).

  Ver [Importar eventos](/es/api-reference/bulk-imports/import-user-events) y [Validar CSV](/es/api-reference/bulk-imports/validate-csv).
</Update>

<Update label="2026-07-01" description="Create reglas: revisión IA obligatoria + provenance" tags={["Rules", "API"]}>
  ## `POST /rules` — revisión IA síncrona en toda alta

  * Las reglas nuevas quedan siempre en **`in_progress`** con **`enabled: false`**; `status` / `enabled` del body se ignoran en create.
  * La respuesta incluye **`aiReview`** y puede tardar varios segundos.
  * Body opcional **`creationProvenance`**: origen (`user`, `agent`, `import_json`, `template`, `bundle`, `api`) e ids de chat del agente.
  * La revisión se audita pero **no debita** tokens de IA.

  Ver [Crear regla](/es/api-reference/rules/create).
</Update>

<Update label="2026-06-26" description="Webhooks de seguridad: campos de contexto de invitación" tags={["Webhooks", "Security", "IAM"]}>
  ## `security.member.invited` / `security.member.created` — `payload.context` ampliado

  **Aditivo.** Los webhooks del ciclo de invitación incluyen metadata de correlación y acceso en `payload.context`:

  * `invitationId` — correlacionar `invited` → `created`
  * `granularRoleIds`, `granularRoleIdsSandbox`
  * `includeProduction`, `includeSandbox`
  * `teamId`, `teamIdSandbox`
  * `hasEnvironmentAccess` — flag de acceso para la org del sobre
  * `environment` — `"production"` o `"sandbox"` según la org del sobre
  * `invitedByUserId`, `acceptedVia` (en `created`)
  * `syncPartialFailure`, `syncErrorMessage` (en `created` cuando la configuración secundaria no se completó)

  Los campos existentes no cambian. Ver [Eventos de webhooks de seguridad](/es/webhooks/events/security-events).
</Update>

<Update label="2026-06-26" description="Batch import: polling de job por jobId" tags={["API", "Bulk imports"]}>
  ## Polling de jobs batch import

  **Aditivo.** Nuevo endpoint canónico para consultar un job de importación batch sin recorrer el histórico paginado.

  ### Endpoints HTTP

  * `GET /batch-import/jobs/{jobId}` — lookup directo por job id (entidades, transacciones y user events). Devuelve `status`, contadores (`totalItems`, `succeeded`, `failed`, `skipped`), timestamps y `jobFailure` opcional si abortó el job completo. Query opcional `include=failures` devuelve el mismo JSON que los endpoints de failures por tipo.
  * `GET /batch-import/unified-history` — nuevo query param **`jobId`** (coincidencia exacta; 0 o 1 fila). El histórico unificado sigue siendo para listados; usar `GET /batch-import/jobs/{jobId}` para polling post-upload.

  ### Flujo recomendado para integradores

  Upload (`202` + `jobId`) → poll `GET /batch-import/jobs/{jobId}` cada 2–5 s hasta status terminal → descargar fallos si hace falta.

  Ver [Consultar estado de job batch](/es/api-reference/bulk-imports/get-batch-job-status) y [Historial unificado](/es/api-reference/bulk-imports/list-unified-history).
</Update>

<Update label="2026-06-25" description="Inteligencia de titulares: exists + accounts-count + metrics" tags={["Marketplace", "API", "Rules"]}>
  ## Inteligencia de Titulares CBU/CVU (`ar_gueno_holder_intelligence_service`)

  **Aditivo.** Endpoint de totales renombrado a `accounts-count` (antes `cbu-count` en desarrollo). Devuelve `snapshotDate`, `isNew`, `cbuCount`, `cvuCount` y `totalAccounts`.

  ### Endpoints HTTP

  * `GET /api/integration-services/ar_gueno_holder_intelligence_service/health` — disponibilidad y frescura del corpus (`status`, `corpusFreshnessDate`). **Sin cobro.**
  * `GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/exists` — pertenencia al corpus. Devuelve `found` y `snapshotDate` (`null` si no existe). Siempre HTTP `200` en éxito (incluso `found: false`). **Sin cobro.**
  * `GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/accounts-count` — totales CBU/CVU + `isNew` y `snapshotDate`. **Cobro por request** cuando el producto tiene precio.
  * `GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/metrics` — lookback densificado (`lookback` 1–180 **o** preset `window` `w_1d`…`w_180d`). Query opcional `date` (`YYYY-MM-DD`, fin inclusive). Devuelve aliases de stock, deltas, `%`, varianza y aceleración. **Cobro por request** cuando el producto tiene precio. Errores: `400` `LOOKBACK_REQUIRED` / `INVALID_LOOKBACK` / `INVALID_WINDOW` / `INVALID_DATE`, `404` `CUIT_NOT_FOUND`, `422` `INCOMPLETE_WINDOW` / `NO_INCREMENTAL_STATE`.

  ### Motor de reglas

  Nuevos campos bajo `services.holder_intelligence.*`: `found`, `snapshot_date`, `cbu_quantity`, `cvu_quantity`, `total_accounts` y `metrics.*` con `holderIntelligenceLookbackDays` (1–180) por condición. En reglas de transacción la ventana termina en `transactedAt` por defecto. Las métricas disparan un fetch upstream cobrable separado.

  Ver [Códigos de proveedor](/es/api-reference/integrations/provider-codes) y la sección [Servicios marketplace](/es/api-reference/services/overview).
</Update>

<Update label="2026-06-26" description="Documentación sección Servicios marketplace" tags={["Docs", "Marketplace", "API"]}>
  ## Documentación Servicios (en / es / pt)

  Nueva sección **Servicios** en Mintlify: overview, guía por servicio y una página por endpoint HTTP para `ar_gueno_holder_intelligence_service`. [Overview](/es/api-reference/services/overview).
</Update>

<Update label="2026-06-24" description="KYC y biométrico: entityTaxId / entityExternalId" tags={["KYC", "Biometric", "API", "Entities"]}>
  ## Identificadores de entidad además de `entityId`

  **Aditivo — compatible hacia atrás.** Clientes que envían solo `entityId` no cambian.

  ### Creación (POST)

  * `POST /api/kyc/validations` — body acepta **`entityId`**, **`entityExternalId`** o **`entityTaxId`** (exactamente uno).
  * `POST /api/kyc/biometric/sessions` — mismas opciones.

  Gu1 resuelve a UUID interno. **`404 NOT_FOUND`** si no hay entidad persistida.

  ### Lectura (GET)

  * `GET /api/kyc/validations?entityTaxId=...` o `?entityExternalId=...`
  * `GET /api/kyc/biometric/sessions?entityTaxId=...` o `?entityExternalId=...`
  * KYC: `GET /api/kyc/entities/by-tax-id/:taxId/current|validations|status` y rutas `by-external-id`
  * Biométrico: `GET /api/kyc/biometric/entities/by-tax-id/:taxId/current` y `by-external-id`

  ### Vista previa sandbox (solo GET)

  * `GET /api/entities/by-tax-id/{taxId}` y `GET /api/entities?taxId=...` pueden devolver datos sintéticos **`sandboxMock: true`** (`id: null`) para números del catálogo sin fila real. **No** habilita POST sin crear entidad real.

  Ver [Crear validación KYC](/es/use-cases/kyc/create-validation), [Sesión biométrica embebida](/es/use-cases/kyc/embedded-biometric) y [Datos mock sandbox](/es/use-cases/kyc/sandbox-mock-data).
</Update>

<Update label="2026-06-23" description="KYC y biométrico: IDs bloqueantes en 409" tags={["KYC", "Biometric", "API"]}>
  ## Respuestas 409 aditivas para sesiones / validaciones abiertas

  **Sin breaking change** para clientes que solo leen `error` y `message`. Campos opcionales nuevos en códigos `409` existentes:

  ### Biometría embebida — `POST /api/kyc/biometric/sessions`

  * Con la última sesión en `pending` o `in_progress`, el create **siempre** devuelve **`409 ACTIVE_SESSION_EXISTS`** (nunca `201` con la misma sesión pending).
  * El body incluye **`activeSessionId`** para cancelar: `POST .../sessions/{activeSessionId}/cancel`.

  ### Validación KYC — `POST /api/kyc/validations`

  * Con una validación abierta (`pending`, `in_progress`, `in_review`), el create devuelve **`409 VALIDATION_IN_PROGRESS`**.
  * El body ahora también incluye **`activeValidationId`** para cancelar: `DELETE .../validations/{activeValidationId}/cancel`.

  Ver [Crear validación KYC](/es/use-cases/kyc/create-validation) y [Sesión biométrica embebida](/es/use-cases/kyc/embedded-biometric).
</Update>

<Update label="2026-06-20" description="GET transacción: rulesExecutionSummary opcional en persisted" tags={["API", "Transactions", "Rules"]}>
  ## `includeRulesSummary` en GET de una transacción

  `GET /transactions/{id}` y `GET /transactions/external/{externalId}` aceptan un query param opcional:

  * **`includeRulesSummary=full`** — Agrega **`persisted.rulesExecutionSummary`** desde la fila **más reciente** de `risk_analysis_audits` de esa transacción. **No** se re-ejecutan reglas en la lectura.

  **Default (sin param):** respuesta igual que antes — sin `rulesExecutionSummary` al leer. Usá `full` solo en vistas de detalle o debugging, no en polling masivo de listados.

  Ver [Obtener transacción](/es/api-reference/transactions/get) y [Resumen de ejecución de reglas](/es/api-reference/rules-execution-summary).
</Update>

<Update label="2026-06-19" description="Resumen de reglas: status entidad origen/destino" tags={["API", "Rules", "Transactions"]}>
  ## Campos opcionales en `rulesExecutionSummary`

  Cuando reglas transaccionales usan `updateEntityStatus` con estado de entidad origen o destino, la API puede incluir estos campos **opcionales** (aditivos; clientes existentes sin cambios):

  * **`rulesHit[].actions.originEntityStatus`** / **`destinationEntityStatus`** — configurados en la regla que hizo match.
  * **`actionsExecuted.originEntityStatus`** / **`destinationEntityStatus`** — estados finales de entidad aplicados en esa corrida (junto con **`actionsExecuted.status`** para la transacción).

  Los snapshots de reglas en auditoría conservan la lista completa de acciones configuradas (incluye cambio de estado diferido) para UI e integradores.

  Ver [Resumen de ejecución de reglas](/es/api-reference/rules-execution-summary).
</Update>

<Update label="2026-06-19" description="Webhooks security: miembro unificado + entornos" tags={["Webhooks", "Security", "IAM"]}>
  ## Eventos `security.member.*` (nomenclatura unificada)

  Todos los eventos de IAM sobre personas usan el prefijo **`security.member.*`** (ya no `security.user.*`, `security.team.*` ni `security.channel.*`):

  * **Perfil / contraseña:** `security.member.profile_updated`, `.password_reset`, `.password_generated`
  * **Equipos:** `security.member.team_added`, `.team_removed`, `.team_role_changed`
  * **Canales (org hija):** `security.member.channel_granted`, `.channel_revoked`
  * **Acceso a entornos (production / sandbox):** `security.member.environment_granted`, `.environment_revoked` — distinguidos por `context.environment` (`"production"` | `"sandbox"`)

  Los cambios de membresía en equipos ya no emiten `security.role.assigned` / `security.role.updated` ambiguos.

  **Breaking:** si tenías suscripciones a `security.user.password_*` u otros keys anteriores, actualizá a los equivalentes `security.member.*`.

  Ver [Eventos webhook de seguridad](/es/webhooks/events/security-events).
</Update>

<Update label="2026-06-19" description="Endpoint sesión biométrica actual" tags={["KYC", "Biometric", "API"]}>
  ## `GET /api/kyc/biometric/entities/:entityId/current`

  Alineado con KYC `GET /api/kyc/entities/:entityId/current`:

  * Devuelve la **última sesión biométrica** de la entidad (por `createdAt`), **cualquier estado** (`pending`, `in_progress`, `approved`, `rejected`, …).
  * **`200` con `null`** si la entidad no tiene sesiones biométricas (ya no `404`).
  * En el listado, `currentSessionId` sigue siendo solo la última sesión **`approved`**.

  El **`409 ACTIVE_SESSION_EXISTS`** al crear incluye **`activeSessionId`** para cancelar la sesión bloqueante sin consulta extra.

  Ver [Sesión biométrica actual](/es/use-cases/kyc/current-biometric-session).
</Update>

<Update label="2026-06-18" description="Eventos webhook de Seguridad e IAM" tags={["Webhooks", "Security", "IAM"]}>
  ## Eventos webhook de seguridad (`security.*`)

  Nueva categoría outbound para monitoreo **Seguridad / IAM** (integraciones SIEM). Suscríbase en **Webhooks → Configuración** a eventos como:

  * **Auth:** `security.auth.login_succeeded`, `security.auth.logout`, `security.auth.login_failed`
  * **Miembros:** `security.member.invited`, `.created`, `.removed`, `.activated`, `.deactivated`
  * **Roles:** `security.role.created`, `.updated`, `.deleted`, `.assigned`, `.revoked`
  * **RBAC:** `security.rbac.granular_toggled`
  * **Contraseña (admin):** `security.member.password_reset`, `security.member.password_generated` (antes `security.user.password_*`)
  * **Settings:** `security.settings.updated` (sandbox, parámetros de seguridad auditados)

  El payload incluye `actionAt`, `actor`, `affectedUser`, `description`, `changes` (anterior/actual) y `context` (IP, user agent, scope).

  **No cubierto:** cambio de contraseña self-service en Clerk, MFA/SSO en Clerk, auth por API key.

  Ver [Eventos webhook de seguridad](/es/webhooks/events/security-events).
</Update>

<Update label="2026-06-18" description="watchFields en matrices + entity_updated en runtime" tags={["Risk matrices", "Entities", "Transactions", "API"]}>
  ## Triggers granulares de matriz (`watchFields`)

  Los triggers **`entity_updated`** (entidades y transacción actualizada en KYT) admiten **`watchFields`** opcional: paths del motor de reglas (p. ej. `email`, `phone`, `attributes.clientTypes`, `metadata.email`). Vacío o ausente = cualquier cambio dispara la matriz (retrocompatible). Con valores, la matriz corre solo si cambió al menos un path listado.

  Configurable en el editor de matrices (pestaña Triggers) o en `risk_matrices.triggers[]` vía API.

  ## Actualización de entidad — `entity_updated` cableado

  `PATCH /entities/{id}` (y por external ID / tax ID) ejecuta matrices asignadas con trigger **`entity_updated`**, salvo `skipRulesExecution: true`. El webhook `entity.updated` incluye `rulesExecutionSummary`. Ver [Actualizar entidad](/es/api-reference/entities/update).

  `PATCH` de transacción con `executeRules=true` pasa los paths cambiados al mismo filtro.
</Update>

<Update label="2026-06-17" description="Import bulk entidades — política de enrichments en hijos" tags={["Entities", "Bulk import", "API"]}>
  ## Import bulk automático — enrichments en hijos y alcance de monitoreo

  **`POST /batch-import/import/entities`** e import bulk JSON aceptan (modo automático, `depth` > 0):

  * **`childEnrichmentPolicy`**: `all_active` (default), `by_root_type` o `basic_only`.
    * **`by_root_type`**: filas empresa → accionistas con todos los enrichments activos **excepto** `global_gueno_sanctions_enrichment`; filas persona → relacionadas solo con **datos básicos** del proveedor de la raíz.
  * **`monitoringApplyToRelationships`**: con `false`, `monitoring` solo en entidades principales. Default `true` con `depth` > 0 si se omite.

  La UI de importación masiva expone los mismos controles. Ver [Importar entidades (bulk)](/es/api-reference/bulk-imports/import-entities#enrichments-en-hijos-y-monitoreo).
</Update>

<Update label="2026-06-16" description="Eventos pre-login del SDK y remote config" tags={["Events", "SDK", "API"]}>
  ## Eventos — campos de sesión del SDK y pre-login

  `POST /events/user` ahora acepta dos campos opcionales: **`sessionId`** (id de sesión del SDK, `sess_...`) y **`sdkSignals`** (señales estructuradas del SDK — flags de integridad y comportamiento, separadas del `metadata`). Ambos se persisten en el evento. **Omitirlos mantiene el comportamiento anterior byte a byte.**

  Para organizaciones con el SDK habilitado, un evento que trae **solo un `sessionId`** (sin `entityId`/`entityExternalId`/`taxId`) ahora se acepta y se guarda como **evento anónimo pre-login** en lugar de devolver error; se vincula a la entidad más tarde, en el primer evento que traiga `sessionId` y un identificador de entidad juntos. Sin el SDK habilitado, sigue siendo obligatorio un identificador de entidad (misma respuesta que antes).

  ## Eventos — nuevos tipos

  Se agregaron tres tipos de evento del SDK: **`SESSION_STARTED`**, **`SESSION_IDENTIFIED`**, **`SCREEN_VIEW`**. Los clientes existentes no se ven afectados.

  ## Nuevo endpoint — `GET /sdk/config`

  Devuelve el remote config del SDK (toggles de señales + defaults de transporte) más el flag `sdkEnabled` de la organización.

  Ver [Crear Evento de Usuario](/es/api-reference/events/create).
</Update>

<Update label="2026-06-15" description="Errores de enrichment y validación de tax ID" tags={["Enrichment", "Entities", "API"]}>
  ## Enrichment marketplace — errores estructurados

  `POST /integration-execution/marketplace/enrichment` devuelve objetos `error` más ricos: `category`, `retryable` y `statusCode` opcionales.

  ## Creación automática / bulk — tax ID estricto

  `taxId` debe ser solo el identificador fiscal; valores fusionados con columnas extra se rechazan con `INVALID_TAX_ID`.

  ## Transacciones — `exchangeRate` opcional (fallback)

  `POST /transactions` y batch aceptan **`exchangeRate` opcional** por transacción. **Sin este campo, el comportamiento es el mismo de siempre** (conversión automática).

  Solo se usa si falla la conversión automática. Semántica: unidades de moneda base por 1 unidad de `currency`; monto normalizado en base = `amount × exchangeRate`. `rateSource: client-provided`.

  **No convertibles hoy (sin tasa automática):** `WLD` (Worldcoin), `ETH` (Ethereum). Enviá `exchangeRate` para monto normalizado en moneda base y reglas que dependen de conversión.

  Ver [Crear transacción — Conversión de moneda](/es/api-reference/transactions/create#conversión-de-moneda).
</Update>

<Update label="2026-06-11" description="Entidades — refresh scope y preserve" tags={["Entities", "Enrichment", "API", "Docs"]}>
  ## `POST /entities/{entityId}/refresh` — scope unificado y sync seguro

  Campos opcionales nuevos (retrocompatibles si se omiten):

  * **`refreshScope`**: `basic_data` | `all_active` | `selected` (+ `providerCodes` si `selected`).
  * **`preserveName`**: `true` conserva el nombre; omitido = sync legacy desde `fullName` normalizado.
  * **`preserveEntityData`**: solo con `refreshScope: "basic_data"` — `true` completa vacíos en `entityData`, `false` reemplaza; omitido = no tocar ficha.

  `basic_data` siempre es solo entidad raíz (sin socios), sin importar `depth`.

  Ver [Actualizar entidad](/es/api-reference/entities/refresh). Payloads existentes sin estos campos no cambian de comportamiento.
</Update>

<Update label="2026-06-11" description="KYC — warning duplicado cross-entity" tags={["KYC", "API", "Docs"]}>
  ## Warning `GUENO_CROSS_ENTITY_DUPLICATED`

  Cuando Gu1 resuelve referencias duplicadas del proveedor en **otra entidad** de la misma organización (`metadata.kycCrossEntityDuplicates.matches`):

  * Añade **`GUENO_CROSS_ENTITY_DUPLICATED`** a `warnings` de la validación por sesión.
  * Si el proveedor mapeó **`approved`**, Gu1 deja el estado en **`in_review`** (`metadata.guenoCrossEntityDuplicateEscalation`).
  * **No omitible:** no puede ir en `omitWarnings` (400) y bloquea auto-aprobación por omit.

  Ver [Códigos de advertencia KYC](/es/use-cases/kyc/warning-risk-codes) y [`omitWarnings`](/es/use-cases/kyc/create-validation).
</Update>

<Update label="2026-06-11" description="KYC — Gu1 Biometría" tags={["KYC", "API", "Webhooks", "Docs"]}>
  ## Gu1 Biometría (`POST /api/kyc/biometric` y `/api/kyc/biometric/sessions`)

  Re-autenticación tras KYC aprobado: verificación por imagen (`POST /api/kyc/biometric`) o sesión con **UI hospedada** (`sessionUrl`, `iframeAllow`, `hostedSessionId`, `webhookUrl` opcional, webhooks `biometric.session_*`, veredicto **Gu1** con `rejectionCode`). Producto marketplace `global_gueno_biometric_kyc`. Ver [Verificación biométrica](/es/use-cases/kyc/biometric) y [Sesión biométrica](/es/use-cases/kyc/embedded-biometric).
</Update>

<Update label="2026-06-10" description="KYC — decision con forma dual array/objeto" tags={["KYC", "API", "Webhooks", "Docs"]}>
  ## `decision` siempre incluye pares array + objeto por feature

  Al persistir (sync, webhook, ingest manual), Gu1 **normaliza** `decision` para que integradores lean indistintamente claves singulares legacy o arrays:

  * `id_verification` ↔ `id_verifications[0]`
  * `liveness` ↔ `liveness_checks[0]`
  * `face_match` ↔ `face_matches[0]`
  * `aml_screening` ↔ `aml_screenings[0]`
  * `ip_analysis` ↔ `ip_analyses[0]`

  Si venían ambas formas, **`array[0]` gana** y el objeto singular se sincroniza. Aplica a GET de validación y webhooks KYC (`payload.decision`).

  Ejemplos Mintlify actualizados con `decision` **completo** (sin branding de vendor; media como claves `kyc/...`). Ver [Eventos webhook KYC](/es/webhooks/events/kyc-events#objeto-decision-payloaddecision).
</Update>

<Update label="2026-06-10" description="Matriz de riesgo — rulesEngineConfig en analyze" tags={["Entities", "Risk Matrix", "API", "Docs"]}>
  ## Config del motor en `POST /entities/{entityId}/analyze`

  Nuevo objeto opcional **`rulesEngineConfig`**: **`partialCoverage`** (cobertura por matriz) y **`omitCoverage`** (omitir gates de cobertura). Defaults `false` — sin cambio vs comportamiento histórico.

  Ver [Analizar entidad](/es/api-reference/entities/analyze).
</Update>

<Update label="2026-06-09" description="KYC — extractedData.ejemplar (DNI argentino)" tags={["KYC", "API", "Docs"]}>
  ## `ejemplar` en extractedData

  Las verificaciones de DNI argentino pueden incluir **`extractedData.ejemplar`** (`A`–`D`) en validaciones KYC y registros de ID Verification (GET, sync, webhooks).

  Con **`doubleCheckRenaper: true`**, **`comparisonResults.ejemplar`** compara OCR vs RENAPER; un mismatch agrega **`RENAPER_EJEMPLAR_NOT_MATCH`** a **`warnings`**.

  Ver [campos de extractedData](/es/use-cases/kyc/id-verification#campos-de-extracteddata) y [doble chequeo RENAPER](/es/use-cases/kyc/create-validation#doble-chequeo-renaper-argentina).
</Update>

<Update label="2026-06-05" description="KYC — flujo RENAPER y revisión manual" tags={["KYC", "API", "Docs"]}>
  ## Doble chequeo RENAPER en validaciones KYC

  Con `doubleCheckRenaper: true`, `metadata.responseDoubleChecks.renaper` incluye **`comparisonResults`**, **`renaperBiometric`** (cuando aplica) y códigos RENAPER en **`warnings`** (p. ej. `RENAPER_TRAMITE_ID_NOT_MATCH`, `RENAPER_EXPIRY_NOT_MATCH`) **sin reemplazar** advertencias de la verificación OCR KYC.

  **Enforce (rechazo automático):** solo si la verificación OCR KYC devuelve el estado **`approved`**. En **`in_review`** y **`rejected`** el chequeo es informativo y deja datos en metadata. **`POST /api/kyc/validations/{id}/approve`** desde `in_review` **no** re-ejecuta RENAPER.

  Ver [Crear validación KYC](/es/use-cases/kyc/create-validation#cuándo-renaper-aplica-enforce-rechazo-automático) y [Aprobar validación](/es/use-cases/kyc/approve-validation).
</Update>

<Update label="2026-06-04" description="Marketplace — checks eliminados, solo enrichments" tags={["Entities", "Enrichment", "API", "Docs"]}>
  ## Producto marketplace `*_check` eliminado

  * **Eliminado:** códigos `*_check`, `POST /integration-execution/marketplace/check`, triggers/acciones de reglas `check_completed` / `execute_check`, y permisos RBAC `checks:read` / `checks:execute`.
  * **Usar en su lugar:** el `*_enrichment` equivalente con [Ejecutar enrichment](/es/api-reference/enrichment/execute-by-id).
  * **Compat legacy:** payloads de create/import con `checks`, `executeAllActiveChecks` o `*_check` en `autoExecuteIntegrations.enrichments` se **ignoran al parsear**.

  Ver [Códigos de proveedores](/es/api-reference/integrations/provider-codes), [Crear entidad](/es/api-reference/entities/create) y [Crear automáticamente](/es/api-reference/entities/create-automatic).
</Update>

<Update label="2026-06-04" description="Bulk imports — códigos de fallo + JSON" tags={["Bulk imports", "API", "Docs"]}>
  ## Códigos estables y endpoints JSON de fallos batch

  * Fallos por fila con **`code`** + **`message`** — [Catálogo](/es/api-reference/bulk-imports/batch-import-failure-codes). CSV incluye columna `code`.
  * **JSON:** `GET /batch-import/transaction-jobs/{jobId}/failures`, `GET /batch-import/user-event-jobs/{jobId}/failures`, `GET /batch-import/entity-jobs/{jobId}/failures` — incluyen `failures[]`, `jobFailure` opcional, `skips[]` en entidades, `truncated` / `failuresTotal` (máx. 500).
  * **CSV:** mismas rutas con sufijo `.csv` para descarga directa.
</Update>

<Update label="2026-06-04" description="Entidades — PATCH riskMatrixIds" tags={["Entities", "API", "Docs"]}>
  ## Asignar matrices de riesgo al actualizar entidad

  * **`PATCH /entities/{id}`** (y **`PATCH /entities/by-external-id/{externalId}`**, **`PATCH /entities/by-tax-id/{taxId}`**): documentados **`riskMatrixIds`** (`string[]`) y **`riskMatrixId`** (`string | string[] | null`) — misma normalización que en create. Solo asigna matrices; **no** ejecuta el motor de reglas (usar [Analizar entidad](/en/api-reference/entities/analyze) o triggers del ciclo de vida).
  * Mintlify actualizado en `/en/`, `/es/`, `/pt/` en [Actualizar entidad](/es/api-reference/entities/update) y [Actualizar por ID externo](/es/api-reference/entities/update-by-external-id).
</Update>

<Update label="2026-06-03" description="Transacciones — configRulesExecution.notifications" tags={["Transactions", "Rules", "API", "Docs"]}>
  ## `configRulesExecution` en alta de transacción

  * **`POST /transactions`**: objeto opcional en el body **`configRulesExecution`** con **`notifications`** (`boolean`). Con `false`, gu1 omite **notificaciones in-app** de la evaluación de reglas (matriz / estado). Acciones **`createAlert`** e investigaciones no cambian.
  * **Default:** si se omite el objeto, el resto de organizaciones mantiene el comportamiento anterior (`notifications` efectivamente `true`). **Paytime prod** (`3bc1f621-27d4-423e-9d64-86680bec2388`) usa **`notifications: false`** por defecto.
  * **Legacy KYT** `POST /legacy/kyt/verifyTransaction`: mismo campo en el body Gu2; Paytime prod **`notifications: false`** por defecto si se omite.
  * Aplica en reglas **sync y async** (`asyncRules`).

  Ver [Crear transacción](/es/api-reference/transactions/create). Paridad en `/en/` y `/pt/`.
</Update>

<Update label="2026-06-02" description="Transacciones — denormalización canónica al vincular entidad" tags={["Transactions", "API", "Docs"]}>
  ## `POST /transactions` y lote — campos de contraparte vinculados

  Cuando origen o destino queda **vinculado** a persona/empresa (`originEntityId` / auto-link por external o tax id), gu1 **siempre pisa** las columnas denormalizadas desde la entidad antes del insert:

  * `originTaxId` / `destinationTaxId` ← `entities.tax_id`
  * `originExternalId` / `destinationExternalId` ← `entities.external_id`

  Los valores que mande el cliente en esos campos **no se conservan** si difieren de la entidad vinculada. Alinea reglas transaccionales con eventos de usuario bajo los mismos identificadores.

  Documentado en [Crear transacción](/es/api-reference/transactions/create#origen-entidad) y [Crear lote](/es/api-reference/transactions/create-batch).
</Update>

<Update label="2026-06-02" description="Eventos de usuario — prioridad isNewDevice del cliente" tags={["Events", "API", "Docs"]}>
  ## `POST /events/user` — `isNewDevice` respeta el valor del integrador

  * Si envías **`isNewDevice: true` o `false`**, gu1 **persiste exactamente ese valor** (sin sobrescritura en servidor).
  * Si **omitís** el campo, gu1 lo infiere cuando hay **`deviceId` + `deviceDetails`** (registro de dispositivos; `true` si el device es nuevo o `firstSeenAt` está dentro de los últimos **5 minutos**); si no, **`false`**.

  Documentado en [Crear evento de usuario](/es/api-reference/events/create#como-funciona-isnewdevice) y [Overview de eventos](/es/api-reference/events/overview).
</Update>

<Update label="2026-06-01" description="Import entidades — dot notation attributes / entityData" tags={["Entities", "Bulk import", "API"]}>
  ## CSV plataforma: `attributes.*` y `entityData.*`

  * Cabeceras con **punto** (misma idea que transacciones nativas): `attributes.segment_tag`, `attributes.tags.tier`, `entityData.income`, `entityData.tradeName`.
  * **`entityData.<campo>`** sin `person`/`company` → bucket según **`type`** de la fila.
  * Columnas **sin prefijo** (`segment_tag`) siguen yendo a `attributes` (retrocompat).
  * Plantillas hub actualizadas; ver [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-06-01" description="Importaciones masivas — límites y manual vs automático" tags={["Bulk import", "API", "Docs"]}>
  ## Límites documentados (en / es / pt)

  * [Importaciones masivas — overview](/es/api-reference/bulk-imports/overview): matriz de **archivos por request**, **filas por plan** e **manual vs automático** en entidades.
  * Páginas por endpoint con límites: [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities), transacciones, eventos de usuario.
  * Consulta límites en runtime: `GET /individual-organization/batch-upload-enabled`.
</Update>

<Update label="2026-06-01" description="Import entidades — países por modo" tags={["Entities", "Bulk import", "API"]}>
  ## Países en import bulk (manual vs automático)

  * **Manual** (`manual`): cualquier **ISO2 válido** de plataforma (lote o `country_code` / `country` por fila). Sin pipeline Nosis/CPF.
  * **Automático** (`automatic`): **AR**, **BR** y **CL** (datos básicos por tax ID, incl. enrichments Chile: ruts.info / BaseAPI).
  * Aplica a **`POST /batch-import/import/entities`** (CSV plataforma y CSV custom con `mappingId`).

  Ver [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-06-01" description="Import entidades — manual multipart alineado" tags={["Entities", "Bulk import", "API"]}>
  ## `POST /batch-import/import/entities` — enrichments en manual

  * El modo **manual** multipart coincide con el hub **Manual**: **`autoExecuteIntegrations`**, **`monitoring`** y matrices opcionales — **sin** pipeline Nosis/CPF.
  * Solo CSV (sin enrichments explícitos) → entidad mínima, sin enrichments.
  * Columnas CSV de enrichment por fila aplican en manual; **`depth`** solo en automático.

  Ver [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-06-01" description="Import entidades — default manual en API" tags={["Entities", "Bulk import", "API"]}>
  ## `POST /batch-import/import/entities` — default manual

  * Sin **`entityImportMode`**, el modo efectivo es **`manual`** (entidad mínima; enrichments solo si los pedís).
  * **Automático** con **`entityImportMode=automatic`** (+ `autoExecuteIntegrations`, `depth`, etc.).
  * Modo manual exige **`suggested_name`** en cada fila (`400` si falta).
  * Respuesta **`202`** incluye **`importMode`** aplicado.

  Ver [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-06-01" description="Import entidades — CSV plataforma sin mappingId" tags={["Entities", "Bulk import", "API"]}>
  ## `POST /batch-import/import/entities` — formato plataforma

  * **`mappingId` opcional** con CSV formato plataforma (`tax_id`, `type`, …). Default de import: **`manual`** (ver entrada siguiente en este changelog).

  Ver [Importar entidades (CSV)](/es/api-reference/bulk-imports/import-entities).
</Update>

<Update label="2026-06-01" description="Evaluación asíncrona de reglas en create" tags={["Transactions", "Rules", "API"]}>
  ## `asyncRules` al crear transacción

  * **`POST /transactions`**: flag opcional **`asyncRules`** en query o body (default **`false`**). Con `true` y `executeRules` distinto de `false`, la transacción se crea en la misma request pero las reglas corren **en background** vía cola de jobs. La respuesta HTTP vuelve al instante con `rulesHit` / `rulesNoHit` vacíos, más **`asyncRules: true`** y **`rulesEvaluationStatus: "queued"`**.
  * **Sin cambio por defecto:** omitir `asyncRules` mantiene ejecución **síncrona** y un `rulesExecutionSummary` completo — clientes existentes siguen igual.
  * **Legacy KYT** `POST /legacy/kyt/verifyTransaction`: mismo flag por query o campo en body Gu2. **Paytime prod** (`3bc1f621-27d4-423e-9d64-86680bec2388`) usa async por defecto si no envían el flag; `asyncRules=false` fuerza sync en una request.
  * **No aplica a batch.** Si Redis/cola no está disponible, puede responder **503** `ASYNC_RULES_QUEUE_UNAVAILABLE` (la transacción puede existir — revisar el body antes de reintentar).

  Ver [Crear transacción](/es/api-reference/transactions/create).
</Update>

<Update label="2026-05-29" description="Face Match e ID Verification — doble chequeo RENAPER" tags={["KYC", "API"]}>
  ## Doble chequeo RENAPER en endpoints KYC standalone

  * **`POST /api/kyc/face-match`**: `doubleCheckRenaper` opcional (body o query). Tras aprobar face match: RENAPER **biométrico** + **datos**. Requiere `documentNumber`, `gender`, `personalNumber` (fallback de entidad para DNI/género). Respuesta con `responseDoubleChecks`.
  * **`POST /api/kyc/id-verification`**: mismo flag; tras OCR approved solo chequeo **datos** RENAPER. Fallo → `declined` + códigos en `warnings`.
  * Credenciales RENAPER de org (igual que KYC por sesión). Timeout HTTP ≥ 60 s en face-match con double-check.

  Ver [Face Match](/es/use-cases/kyc/face-match) e [ID Verification](/es/use-cases/kyc/id-verification).
</Update>

<Update label="2026-05-29" description="Trigger status-change en reglas KYT" tags={["Transactions", "Rules", "API"]}>
  ## KYT — triggers separados: cambio de estado vs actualización de campos

  * **`PATCH …/changeStatus`** ejecuta reglas/matrices con trigger **`status_changed`** (`trigger_transaction_status_changed`), no `updated`.
  * **`PATCH /transactions/{id}`** con `executeRules=true` sigue usando **`updated`** (`trigger_transaction_updated`) para cambios de **metadata**, **deviceDetails**, **channel** o **reason**.
  * **Migración:** reconfigurar reglas que debían correr al cambiar estado al nuevo trigger (Rule Builder: *Al cambiar estado*; matrices: `transaction_status_changed`).

  Ver [Cambiar estado](/es/use-cases/transaction-monitoring/change-status-api) y [Actualizar transacción](/es/api-reference/transactions/update).
</Update>

<Update label="2026-05-29" description="PATCH transacción — metadata, deviceDetails, channel, reason" tags={["Transactions", "API"]}>
  ## Actualización parcial de transacción

  * **`PATCH /transactions/{id}`** y **`PATCH /transactions/external/{externalId}`**: actualizar **`metadata`** (merge superficial), **`deviceDetails`** (merge superficial en `device_details`), **`channel`** (nullable) y/o **`reason`** (enum). Requiere `transactions:edit`.
  * Query **`executeRules=true`** re-ejecuta reglas KYT con trigger **`updated`** — no reglas de cambio de estado.
  * Auditoría `transaction_updated` y webhook `transaction.updated` con mapa `changes` (incluye `deviceDetails` si aplica).

  Ver [Actualizar transacción](/es/api-reference/transactions/update).
</Update>

<Update label="2026-05-29" description="¿Tiene eventos? — identificadores por query" tags={["Events", "API"]}>
  ## Eventos de usuario — has-events por external ID o tax ID

  * **`GET /events/user/entity/has-events`** (nuevo): comprobación sí/no sin UUID interno. Query params: `entity_id`, `entity_external_id` o `tax_id` (al menos uno obligatorio). Prioridad: `entity_id` → `entity_external_id` → `tax_id`; comparación de tax ID con normalización (sin caracteres no alfanuméricos).
  * La respuesta incluye **`entityId`** resuelto para poder llamar a [Listar por entidad](/es/api-reference/events/list-by-entity) cuando `hasEvents` es true.
  * **`GET /events/user/entity/{entityId}/has-events`** sigue soportado (contrato sin cambios).

  Ver [¿Tiene eventos? (por entidad)](/es/api-reference/events/has-events-by-entity).
</Update>

<Update label="2026-05-28" description="Códigos de advertencia IP analysis KYC" tags={["KYC", "API"]}>
  ## KYC por sesión — advertencias de análisis de dispositivo e IP

  * **`GET /api/kyc/validations/:id`** (y rutas de sync/webhook): el array **`warnings`** ahora fusiona códigos **`risk`** de **`decision.ip_analyses[].warnings[]`** (y legacy `decision.ip_analysis.warnings`), además de verificación de documento, liveness, face match y AML.
  * Ocho códigos del proveedor (p. ej. `PRIVATE_NETWORK_DETECTED`, `DUPLICATED_DEVICE_FINGERPRINT`, `IP_ADDRESS_IN_BLOCKLIST`). Ver [Códigos de advertencia KYC — Análisis de dispositivo e IP](/es/use-cases/kyc/warning-risk-codes#análisis-de-dispositivo-e-ip-kyc-por-sesión).
  * Los mismos códigos son válidos en **`omitWarnings`** de [`POST /api/kyc/validations`](/es/use-cases/kyc/create-validation) al auto-aprobar sesiones en `in_review`.

  **Nota para integradores:** las validaciones existentes conservan su `warnings` hasta el próximo sync; volvé a consultar o sincronizá para backfillear códigos de IP analysis en filas antiguas.
</Update>

<Update label="2026-05-26" description="ID Verification — extractedData ampliado" tags={["KYC", "API"]}>
  ## ID Verification — `extractedData` más completo

  * **`POST /api/kyc/id-verification`** y auditoría list/get persisten y devuelven un `extractedData` más amplio: identidad (`personalNumber`, `taxNumber`, `placeOfBirth`, …), `providerStatus`, `warningMeta` (p. ej. sesión duplicada), scores de calidad, `extraFields`, `mrz`, `parsedAddress`, `barcodes` cuando los devuelve el servicio ID Verification de Gu1.
  * **`warnings`** sigue siendo un array de códigos de riesgo para i18n; la metadata estructurada de duplicados va en `warningMeta` dentro de `extractedData`.
  * No se devuelven URLs externas de imagen ni base64; las imágenes subidas están en [imágenes ID Verification](/es/use-cases/kyc/id-verification-images).
  * **`debugProviderResponse`** solo en entornos no productivos de la API Gu1 (payload de verificación sanitizado, sin imágenes).

  Ver [ID Verification](/es/use-cases/kyc/id-verification#campos-de-extracteddata).
</Update>

<Update label="2026-05-26" description="operationalHours en entidades + reglas KYT" tags={["Entidades", "Transacciones", "Reglas", "API"]}>
  ## Horario operativo por entidad (global)

  * **Entidades:** campo opcional en raíz `operationalHours` (`timezone` enum + `weekly`). Aplica a `person` y `company`, manual y `POST /entities/automatic`. Columna `entities.operational_hours`. Ver [Crear entidad](/es/api-reference/entities/create), [person/create](/es/api-reference/person/create) y [create-automatic](/es/api-reference/person/create-automatic).
  * **Transacciones:** enum `transaction_time_zone` ampliado (zonas Brasil). `timeZone` independiente de `operationalHours`. **`transactedAt`:** UTC en DB; ISO con `Z` sin cambios para clientes actuales; datetime local + `timeZone` opcional convierte a UTC.
  * **Reglas:** operadores `outside_entity_operational_hours` e `inside_entity_operational_hours` sobre `transactedAt` (`value`: `origin` | `destination`).

  Ver [Crear transacción](/es/api-reference/transactions/create).
</Update>

<Update label="2026-05-22" description="timeZone opcional en transacciones" tags={["Transacciones", "API", "Base de datos"]}>
  ## `timeZone` en transacciones

  * **Base de datos:** Nueva columna nullable `time_zone` en `transactions` con enum `transaction_time_zone` (valores IANA como `America/Argentina/Buenos_Aires`, `UTC`, etc.). Las filas existentes siguen en `null`.
  * **API:** `timeZone` opcional en `POST /transactions` y creación en lote; se devuelve en `GET /transactions/{id}` y `GET /transactions/external/{externalId}` como `string | null`.

  Ver [Enum zona horaria](/es/api-reference/transactions/time-zone-enum) y [Crear transacción](/es/api-reference/transactions/create).
</Update>

<Update label="2026-05-21" description="validateExistingEntity en transacciones" tags={["Transacciones", "API", "Legacy"]}>
  ## `validateExistingEntity` (creación de transacciones)

  * **`POST /transactions`**: nuevo campo opcional `validateExistingEntity` (default **`false`**). Con `true`, cada identificador de origen/destino que envíes debe existir en la org; si no, **400** `INVALID_ENTITY_REFERENCES` y no se crea la fila.
  * **Batch** (`POST /transactions/batch`, upload, JSON): el default sigue siendo **`true`** (validación estricta si enviás identificadores). Para import histórico permisivo: `validateExistingEntity: false`.
  * **Legacy KYT** `POST /legacy/kyt/verifyTransaction`: acepta el mismo campo en el body Gu2 (`validateExistingEntity`).

  Ver [Crear transacción](/es/api-reference/transactions/create) y [Crear transacciones en lote](/es/api-reference/transactions/create-batch).
</Update>

<Update label="2026-05-21" description="Auto-ejecución en creación de entidades" tags={["Entidades", "API", "Enriquecimiento"]}>
  ## `excludeEnrichments` en creación de entidades

  `autoExecuteIntegrations` y `autoExecuteIntegrationsShareholders` aceptan **`excludeEnrichments`**: códigos de proveedor que se excluyen del conjunto final de enriquecimientos (también con `executeAllActiveEnrichments: true`).

  **`executeAllActiveChecks` y `checks` ya no forman parte del contrato público** de estos objetos; los payloads legacy que los envíen se ignoran al parsear.

  Ver [Crear entidad (automática)](/es/api-reference/entities/create-automatic).
</Update>

<Update label="2025-01-27" description="v1.3.0 - Documentación Página de Onboarding Alojada" tags={["KYC", "Página Alojada", "Documentación"]}>
  ## Nuevo: Documentación de Página de Onboarding Alojada

  Documentación completa para la Página de Onboarding Alojada - la forma más rápida de implementar verificación KYC sin código.

  ### Novedades

  **Documentación de Página Alojada:**

  * ✅ Guía completa de parámetros de personalización (branding, colores, diseño)
  * ✅ Configuración de reglas de validación (verificación de edad, métodos de captura, detección de duplicados)
  * ✅ Reglas de validación de documentos (QR/código de barras, MRZ, fechas de vencimiento, vivacidad)
  * ✅ Guía de integración paso a paso con ejemplos de código
  * ✅ Diagrama de flujo visual mostrando el proceso completo
  * ✅ Mejores prácticas de seguridad para gestión de sesiones
  * ✅ Confirmación de diseño mobile-responsive

  **Características Clave:**

  * 📱 Diseño mobile-responsive para todos los dispositivos
  * 🎨 Personalización completa de colores, branding y diseño
  * 🔒 Directrices de seguridad completas
  * 📊 Diagramas de secuencia visuales para mayor claridad
  * 🌐 Información de canal de soporte para cambios de configuración

  ### Idiomas

  Toda la documentación disponible en:

  * 🇺🇸 English
  * 🇪🇸 Español
  * 🇧🇷 Português

  ### Impacto

  * Implementación más rápida para soluciones sin código
  * Guía clara sobre opciones de personalización
  * Mayor conciencia de seguridad
  * Mejor comprensión del flujo de la página alojada

  [Ver Documentación de Página Alojada](/es/use-cases/kyc/hosted-page)
</Update>

<Update label="2025-01-09" description="v1.2.0 - Mejora Documentación KYC" tags={["KYC", "Documentación", "Multi-idioma"]}>
  ## Refinamiento de Páginas KYC Basado en Feedback del Cliente

  Mejora importante en la documentación de KYC basada en 14 preguntas del feedback de clientes.

  ### Novedades

  **Documentación de Flujo Completo:**

  * ✅ Tabla comparativa completa: Creación Automática vs Manual
  * ✅ Guía completa de configuración de Matriz de Riesgo con instrucciones del dashboard
  * ✅ Aclaración sobre función de accionistas (solo KYB, no KYC)
  * ✅ Referencia de códigos de proveedores con ejemplos de uso
  * ✅ Sección detallada de gestión de créditos con costos y flujos de trabajo

  **Página Overview:**

  * ✅ Explicación Webhooks vs polling manual
  * ✅ Tabla comparativa KYC Completo vs Verificaciones Individuales
  * ✅ Advertencia completa sobre seguridad de face matching para bancos/fintech
  * ✅ Tabla mejorada de endpoints API con casos de uso

  **Página Crear Validación:**

  * ✅ Diagrama de secuencia completo mostrando el flujo completo
  * ✅ Aclaración Sandbox vs Producción
  * ✅ Manejo de entidades duplicadas con ejemplos de código
  * ✅ Documentación expandida de integrationCode

  **API de Entidades:**

  * ✅ Campos opcionales marcados con ejemplos (attributes, entityData)
  * ✅ Ejemplos de creación de entidad mínima vs completa

  ### Idiomas

  Todas las mejoras disponibles en:

  * 🇺🇸 English
  * 🇪🇸 Español
  * 🇧🇷 Português

  ### Impacto

  * 14 preguntas de cliente respondidas inline
  * 12 archivos de documentación actualizados
  * 0 enlaces rotos
  * Experiencia de onboarding de desarrolladores mejorada

  [Ver Documentación KYC](/es/use-cases/kyc/overview)
</Update>

<Update label="2025-01-08" description="v1.1.0 - Soporte Multi-idioma" tags={["Infraestructura", "i18n"]}>
  ## Documentación Multi-idioma Mejorada

  Estructura de documentación mejorada con traducciones completas en español y portugués.

  ### Cambios

  * Cobertura completa de traducción para KYC, KYB y Monitoreo de Transacciones
  * Terminología consistente en todos los idiomas
  * Ejemplos específicos del idioma (DNI para España, CPF para Brasil, etc.)

  ### Idiomas Disponibles

  * Inglés (EN) - Principal
  * Español (ES) - Completo
  * Portugués (PT) - Completo
</Update>

<Update label="2024-12-20" description="v1.0.0 - Lanzamiento Inicial" tags={["Lanzamiento"]}>
  ## Lanzamiento de Documentación gu1

  Lanzamiento inicial de documentación API completa.

  ### Funcionalidades Principales

  * Referencia API completa para todos los endpoints
  * Guías de casos de uso (KYC, KYB, Monitoreo de Transacciones)
  * Guías de integración de webhooks
  * Tutoriales interactivos
  * Soporte multi-idioma

  ### Componentes

  * API de entidades persona
  * API de entidades empresa
  * Flujos de validación KYC
  * Monitoreo de transacciones
  * Motor de reglas
  * Matrices de riesgo
  * Alertas e investigaciones

  [Comenzar](/es/quickstart)
</Update>