Registro de Cambios

​

Enrichment marketplace — errores estructurados

​

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

​

Transacciones — exchangeRate opcional (fallback)

​

POST /entities/{entityId}/refresh — scope unificado y sync seguro

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

​

Warning GUENO_CROSS_ENTITY_DUPLICATED

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

​

Gu1 Biometría (POST /api/kyc/biometric y /api/kyc/biometric/sessions)

​

decision siempre incluye pares array + objeto por feature

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

​

Config del motor en POST /entities/{entityId}/analyze

​

ejemplar en extractedData

​

Doble chequeo RENAPER en validaciones KYC

​

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.
• Compat legacy: payloads de create/import con checks, executeAllActiveChecks o *_check en autoExecuteIntegrations.enrichments se ignoran al parsear.

​

Códigos estables y endpoints JSON de fallos batch

• Fallos por fila con code + message — Catálogo. 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.

​

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 o triggers del ciclo de vida).
• Mintlify actualizado en /en/, /es/, /pt/ en Actualizar entidad y Actualizar por ID externo.

​

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

​

POST /transactions y lote — campos de contraparte vinculados

• originTaxId / destinationTaxId ← entities.tax_id
• originExternalId / destinationExternalId ← entities.external_id

​

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.

​

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

​

Límites documentados (en / es / pt)

• Importaciones masivas — 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), transacciones, eventos de usuario.
• Consulta límites en runtime: GET /individual-organization/batch-upload-enabled.

​

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

​

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.

​

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.

​

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

​

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

​

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.

​

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

​

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

​

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 cuando hasEvents es true.
• GET /events/user/entity/{entityId}/has-events sigue soportado (contrato sin cambios).

​

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.
• Los mismos códigos son válidos en omitWarnings de POST /api/kyc/validations al auto-aprobar sesiones en in_review.

​

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.
• debugProviderResponse solo en entornos no productivos de la API Gu1 (payload de verificación sanitizado, sin imágenes).

​

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, person/create y 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).

​

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.

​

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

​

excludeEnrichments en creación de entidades

​

Nuevo: Documentación de Página de Onboarding Alojada

​

Novedades

• ✅ 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

• 📱 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

• 🇺🇸 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

​

Refinamiento de Páginas KYC Basado en Feedback del Cliente

​

Novedades

• ✅ 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

• ✅ 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

• ✅ 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

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

​

Idiomas

• 🇺🇸 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

​

Documentación Multi-idioma Mejorada

​

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

​

Lanzamiento de Documentación gu1

​

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