Registro de Alterações

​

Enrichment marketplace — erros estruturados

​

Criação automática / bulk — tax ID estrito

​

Transações — exchangeRate opcional (fallback)

​

POST /entities/{entityId}/refresh — escopo unificado e sync seguro

• refreshScope: basic_data | all_active | selected (+ providerCodes se selected).
• preserveName: true mantém o nome; omitido = sync legacy de fullName normalizado.
• preserveEntityData: apenas com refreshScope: "basic_data" — true preenche vazios em entityData, false substitui; omitido = não alterar ficha.

​

Aviso GUENO_CROSS_ENTITY_DUPLICATED

• Adiciona GUENO_CROSS_ENTITY_DUPLICATED a warnings da validação por sessão.
• Se o provedor mapeou approved, Gu1 define o status como in_review (metadata.guenoCrossEntityDuplicateEscalation).
• Não omitível: não pode constar em omitWarnings (400) e bloqueia autoaprovação por omit.

​

Gu1 Biometria (POST /api/kyc/biometric e /api/kyc/biometric/sessions)

​

decision sempre inclui 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 do motor em POST /entities/{entityId}/analyze

​

ejemplar em extractedData

​

Dupla verificação RENAPER em validações KYC

​

Produto marketplace *_check removido

• Removido: códigos *_check, POST /integration-execution/marketplace/check, triggers/ações de regras check_completed / execute_check, e permissões RBAC checks:read / checks:execute.
• Use em vez disso: o *_enrichment correspondente com Executar enrichment.
• Compat legacy: payloads de create/import com checks, executeAllActiveChecks ou *_check em autoExecuteIntegrations.enrichments são ignorados no parse.

​

Códigos estáveis e endpoints JSON de falhas batch

• Falhas por linha com code + message — Catálogo. CSV inclui coluna code.
• JSON: GET /batch-import/transaction-jobs/{jobId}/failures, GET /batch-import/user-event-jobs/{jobId}/failures, GET /batch-import/entity-jobs/{jobId}/failures — incluem failures[], jobFailure opcional, skips[] em entidades, truncated / failuresTotal (máx. 500).
• CSV: mesmas rotas com sufixo .csv para download direto.

​

Atribuir matrizes de risco na atualização de entidade

• PATCH /entities/{id} (e PATCH /entities/by-external-id/{externalId}, PATCH /entities/by-tax-id/{taxId}): documentados riskMatrixIds (string[]) e riskMatrixId (string | string[] | null) — mesma normalização do create. Apenas atribui matrizes; não executa o motor de regras (usar Analisar entidade ou triggers de ciclo de vida).
• Mintlify atualizado em /en/, /es/, /pt/ em Atualizar entidade e Atualizar por ID externo.

​

configRulesExecution na criação de transação

• POST /transactions: objeto opcional no body configRulesExecution com notifications (boolean). Com false, a gu1 não envia notificações in-app da avaliação de regras (matriz / status). Ações createAlert e investigações permanecem iguais.
• Padrão: omitir o objeto mantém o comportamento anterior na maioria das orgs (notifications efetivamente true). Paytime prod (3bc1f621-27d4-423e-9d64-86680bec2388) usa notifications: false por padrão.
• Legacy KYT POST /legacy/kyt/verifyTransaction: mesmo campo no body Gu2; Paytime prod notifications: false por padrão se omitido.
• Vale para regras sync e async (asyncRules).

​

POST /transactions e lote — campos de contraparte vinculados

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

​

POST /events/user — isNewDevice respeita o valor do integrador

• Se você enviar isNewDevice: true ou false, a gu1 persiste exatamente esse valor (sem sobrescrita no servidor).
• Se omitir o campo, a gu1 infere quando há deviceId + deviceDetails (registro de dispositivos; true se o device for novo ou firstSeenAt estiver nos últimos 5 minutos); caso contrário false.

​

CSV plataforma: attributes.* e entityData.*

• Cabeçalhos com ponto (como transações nativas): attributes.segment_tag, entityData.income, entityData.tradeName.
• entityData.<campo> sem person/company → bucket conforme type da linha.
• Colunas sem prefixo permanecem em attributes (retrocompat).
• Ver Importar entidades (CSV).

​

Limites documentados (en / es / pt)

• Importações em lote — overview: matriz de arquivos por request, linhas por plano e manual vs automático em entidades.
• Páginas por endpoint com limites (entidades CSV, transações, eventos).
• Consulta limites em runtime: GET /individual-organization/batch-upload-enabled.

​

Países na importação bulk (manual vs automático)

• Manual (manual): qualquer ISO2 válido da plataforma (lote ou country_code / country por linha). Sem pipeline Nosis/CPF.
• Automático (automatic): AR, BR e CL (dados básicos por tax ID, incl. enrichments Chile: ruts.info / BaseAPI).
• Vale para POST /batch-import/import/entities (CSV plataforma e CSV custom com mappingId).

​

POST /batch-import/import/entities — enrichments no manual

• Modo manual multipart alinhado ao hub Manual: autoExecuteIntegrations, monitoring e matrizes opcionais — sem pipeline Nosis/CPF.
• Só CSV (sem enrichments explícitos) → entidade mínima, sem enrichments.
• Colunas CSV de enrichment por linha aplicam no manual; depth só no automático.

​

POST /batch-import/import/entities — padrão manual

• Sem entityImportMode → manual (entidade mínima; enrichments só se pedidos).
• Automático com entityImportMode=automatic. Resposta 202 inclui importMode.

​

POST /batch-import/import/entities — formato plataforma

• mappingId passa a ser opcional quando o CSV usa cabeçalhos canônicos do hub (tax_id, type, country_code, … — template automático/manual).
• Sem mudança para layouts custom: colunas arbitrárias ainda exigem mappingId (mapeamento salvo).
• CSV simples (tax_id + type apenas): envie country (ISO2, ex. AR) no form multipart como padrão do lote.
• Paridade com transações: formato nativo → sem mapeamento; colunas custom → com mapeamento.

​

asyncRules ao criar transação

• POST /transactions: flag opcional asyncRules em query ou body (padrão false). Com true e executeRules diferente de false, a transação é criada na mesma request mas as regras rodam em background via fila de jobs. A resposta HTTP retorna na hora com rulesHit / rulesNoHit vazios, mais asyncRules: true e rulesEvaluationStatus: "queued".
• Padrão inalterado: omitir asyncRules mantém execução síncrona e rulesExecutionSummary completo — clientes existentes continuam iguais.
• Legacy KYT POST /legacy/kyt/verifyTransaction: mesmo flag via query ou campo no body Gu2. Paytime prod (3bc1f621-27d4-423e-9d64-86680bec2388) usa async por padrão se omitirem o flag; asyncRules=false força sync numa request.
• Não vale para batch. Se Redis/fila indisponível, pode retornar 503 ASYNC_RULES_QUEUE_UNAVAILABLE (a transação pode já existir — conferir o body antes de reenviar).

​

Dupla verificação RENAPER em endpoints KYC standalone

• POST /api/kyc/face-match: doubleCheckRenaper opcional (body ou query). Após face match aprovado: RENAPER biométrico + dados. Requer documentNumber, gender, personalNumber (fallback de entidade para DNI/gênero). Resposta com responseDoubleChecks.
• POST /api/kyc/id-verification: mesmo flag; após OCR approved apenas chequeo dados RENAPER. Falha → declined + códigos em warnings.
• Credenciais RENAPER da org (igual ao KYC por sessão). Timeout HTTP ≥ 60 s no face-match com double-check.

​

KYT — triggers separados: mudança de status vs atualização de campos

• PATCH …/changeStatus executa regras/matrizes com trigger status_changed (trigger_transaction_status_changed), não updated.
• PATCH /transactions/{id} com executeRules=true continua usando updated (trigger_transaction_updated) para alterações de metadata, deviceDetails, channel ou reason.
• Migração: reconfigurar regras que rodavam na mudança de status para o novo trigger (Rule Builder: Mudança de status; matrizes: transaction_status_changed).

​

Atualização parcial de transação

• PATCH /transactions/{id} e PATCH /transactions/external/{externalId}: atualizar metadata (merge superficial), deviceDetails (merge superficial em device_details), channel (nullable) e/ou reason (enum). Requer transactions:edit.
• Query executeRules=true reexecuta regras KYT com trigger updated — não regras de mudança de status.
• Auditoria transaction_updated e webhook transaction.updated com mapa changes (inclui deviceDetails quando aplicável).

​

Eventos de usuário — has-events por external ID ou tax ID

• GET /events/user/entity/has-events (novo): verificação sim/não sem UUID interno. Query params: entity_id, entity_external_id ou tax_id (pelo menos um obrigatório). Prioridade: entity_id → entity_external_id → tax_id; tax ID com normalização (caracteres não alfanuméricos removidos).
• A resposta inclui entityId resolvido para chamar Listar por entidade quando hasEvents for true.
• GET /events/user/entity/{entityId}/has-events continua suportado (contrato inalterado).

​

KYC por sessão — avisos de análise de dispositivo e IP

• GET /api/kyc/validations/:id (e rotas de sync/webhook): o array warnings agora funde códigos risk de decision.ip_analyses[].warnings[] (e legacy decision.ip_analysis.warnings), além de verificação de documento, liveness, face match e AML.
• Oito códigos do provedor (ex.: PRIVATE_NETWORK_DETECTED, DUPLICATED_DEVICE_FINGERPRINT, IP_ADDRESS_IN_BLOCKLIST). Ver Códigos de aviso KYC — Análise de dispositivo e IP.
• Os mesmos códigos são válidos em omitWarnings em POST /api/kyc/validations ao autoaprovar sessões em in_review.

​

ID Verification — extractedData mais completo

• POST /api/kyc/id-verification e auditoria list/get passam a persistir e devolver um extractedData mais amplo: identidade (personalNumber, taxNumber, placeOfBirth, …), providerStatus, warningMeta (ex.: sessão duplicada), pontuações de qualidade, extraFields, mrz, parsedAddress, barcodes quando o serviço ID Verification da Gu1 os devolve.
• warnings continua como array de códigos de risco para i18n; metadados estruturados de duplicado ficam em warningMeta dentro de extractedData.
• URLs externas de imagem e base64 não são devolvidas; imagens enviadas estão em imagens ID Verification.
• debugProviderResponse apenas em ambientes não produtivos da API Gu1 (payload de verificação sanitizado, sem imagens).

​

Horário operativo por entidade (global)

• Entidades: campo opcional na raiz operationalHours (timezone enum + weekly). Coluna entities.operational_hours. Ver Criar entidade.
• Transações: enum transaction_time_zone ampliado (fusos do Brasil). timeZone independente de operationalHours. transactedAt: gravado em UTC; ISO com Z inalterado para clientes atuais; datetime local + timeZone opcional converte para UTC.
• Regras: operadores outside_entity_operational_hours e inside_entity_operational_hours em transactedAt (value: origin | destination).

​

timeZone em transações

• Banco de dados: Nova coluna nullable time_zone em transactions com enum transaction_time_zone (valores IANA como America/Argentina/Buenos_Aires, UTC, etc.). Registros existentes permanecem null.
• API: timeZone opcional em POST /transactions e criação em lote; retornado em GET /transactions/{id} e GET /transactions/external/{externalId} como string | null.

​

validateExistingEntity (criação de transações)

• POST /transactions: campo opcional validateExistingEntity (padrão false). Com true, cada identificador de origem/destino enviado deve existir na org; senão 400 INVALID_ENTITY_REFERENCES e a linha não é criada.
• Lote (POST /transactions/batch, upload, JSON): padrão continua true. Import permissivo: validateExistingEntity: false.
• Legacy KYT POST /legacy/kyt/verifyTransaction: mesmo campo no body Gu2.

​

excludeEnrichments na criação de entidades

​

Novo: Documentação da Página de Onboarding Hospedada

​

Novidades

• ✅ Guia completo de parâmetros de personalização (branding, cores, layout)
• ✅ Configuração de regras de validação (verificação de idade, métodos de captura, detecção de duplicados)
• ✅ Regras de validação de documentos (QR/código de barras, MRZ, datas de validade, vivacidade)
• ✅ Guia de integração passo a passo com exemplos de código
• ✅ Diagrama de fluxo visual mostrando o processo completo
• ✅ Melhores práticas de segurança para gerenciamento de sessões
• ✅ Confirmação de design mobile-responsive

• 📱 Design mobile-responsive para todos os dispositivos
• 🎨 Personalização completa de cores, branding e layout
• 🔒 Diretrizes de segurança abrangentes
• 📊 Diagramas de sequência visuais para clareza
• 🌐 Informações de canal de suporte para alterações de configuração

​

Idiomas

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

​

Impacto

• Implementação mais rápida para soluções sem código
• Orientação clara sobre opções de personalização
• Maior conscientização sobre segurança
• Melhor compreensão do fluxo da página hospedada

​

Refinamento de Páginas KYC Baseado em Feedback do Cliente

​

Novidades

• ✅ Tabela comparativa completa: Criação Automática vs Manual
• ✅ Guia completo de configuração de Matriz de Risco com instruções do dashboard
• ✅ Esclarecimento sobre recurso de acionistas (apenas KYB, não KYC)
• ✅ Referência de códigos de provedores com exemplos de uso
• ✅ Seção detalhada de gestão de créditos com custos e fluxos de trabalho

• ✅ Explicação Webhooks vs polling manual
• ✅ Tabela comparativa KYC Completo vs Verificações Individuais
• ✅ Aviso completo sobre segurança de comparação facial para bancos/fintech
• ✅ Tabela melhorada de endpoints API com casos de uso

• ✅ Diagrama de sequência completo mostrando o fluxo completo
• ✅ Esclarecimento Sandbox vs Produção
• ✅ Tratamento de entidades duplicadas com exemplos de código
• ✅ Documentação expandida de integrationCode

• ✅ Campos opcionais marcados com exemplos (attributes, entityData)
• ✅ Exemplos de criação de entidade mínima vs completa

​

Idiomas

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

​

Impacto

• 14 perguntas de cliente respondidas inline
• 12 arquivos de documentação atualizados
• 0 links quebrados
• Experiência de onboarding de desenvolvedores melhorada

​

Documentação Multi-idioma Aprimorada

​

Mudanças

• Cobertura completa de tradução para KYC, KYB e Monitoramento de Transações
• Terminologia consistente em todos os idiomas
• Exemplos específicos do idioma (CPF para Brasil, DNI para Espanha, etc.)

​

Idiomas Disponíveis

• Inglês (EN) - Principal
• Espanhol (ES) - Completo
• Português (PT) - Completo

​

Lançamento da Documentação gu1

​

Funcionalidades Principais

• Referência API completa para todos os endpoints
• Guias de casos de uso (KYC, KYB, Monitoramento de Transações)
• Guias de integração de webhooks
• Tutoriais interativos
• Suporte multi-idioma

​

Componentes

• API de entidades pessoa
• API de entidades empresa
• Fluxos de validação KYC
• Monitoramento de transações
• Motor de regras
• Matrizes de risco
• Alertas e investigações