Registro de Alterações

​

Idioma configurável de validação

​

Reativação segura de onboarding

​

Compartilhar matrizes, listas e webhooks com canais

​

Reportes manuais de risco transacional

​

Demografia CUIT no accounts-count

​

CNAE principal nas fichas de empresas brasileiras

​

GET de enrichment normalizado e dados atuais

• Obter enrichment normalizado — GET /entities/{id}/normalized-enrichment. Dossiê Gu1 NormalizeType (RootData + consolidadores + summaries). 404 NOT_FOUND se a entidade ainda não tem linha normalizada.
• Obter dados atuais de enrichment — GET /entities/{id}/enrichment-data. Últimos payloads mapped / raw por código de integração. Se a entidade existe mas não há snapshot, HTTP 200 com hasEnrichmentData: false.

​

statusIds nos in-list do CPF

• CUIT in-list: statusIds, asRecipientStatusIds, asInitiatorStatusIds.
• Account in-list: statusIds.

{
  "field": "services.cpf.in_list",
  "operator": "eq",
  "value": true,
  "serviceCuitFieldPath": "destinationTaxId",
  "serviceCpfMode": "both",
  "serviceCpfStatusIds": ["2"]
}

​

Mensagens error para integradores

​

Rotas de contas por external ID e tax ID

• /entities/by-external-id/{externalId}/accounts
• /entities/by-tax-id/{taxId}/accounts

​

Identificação fiscal KYB na Espanha (autônomos)

​

Contas de entidades

​

Espera de rate limit no body do 429

​

Linhas automáticas vs manuais

​

Concorrência de importações em lote e teto de linhas de entidades

​

Retenção por arquivo no histórico

​

Fechamento de importações relacionadas

​

Dispositivos de uma entidade e suas relações diretas

​

jobFailure.code: ARTIFACT_UPLOAD_FAILED e QUEUE_ERROR

• ARTIFACT_UPLOAD_FAILED — não foi possível armazenar o payload ou o arquivo de origem, então o worker não tinha o que retomar.
• QUEUE_ERROR — a fila rejeitou o enfileiramento e o job nunca iniciou.

​

validate-csv: avisos por linha em mapeamentos de transação

• Novo totalRows na raiz, ao lado do sampledRows que já existia.
• Cada entrada de warnings pode trazer field, value, allowedValues e occurrences. Os code, message, row e column existentes não mudam.
• Novo código de aviso INVALID_ENUM_VALUE. Para códigos desconhecidos, use message como fallback.
• Os avisos são agrupados por problema em vez de emitidos por linha: uma entrada informa a primeira linha afetada mais occurrences. Se você contava warnings.length como “linhas com problema”, leia occurrences.

​

Novo status de entidade: awaiting_information

• Você pode enviar status: "awaiting_information" no create ou PATCH como qualquer outro valor de ciclo de vida.
• O analista de onboarding define este status quando envia o e-mail de pedido de documentos e guarda o status anterior no pedido. Quando o merchant envia os documentos (ou o operador aceita/descarta o intake), o Gu1 restaura esse status — salvo se um operador o tiver alterado ou travado enquanto esperava.
• awaiting_information não bloqueia operações como blocked / suspended / rejected.

​

Serviço marketplace: Central de Prevenção de Fraude (CPF)

• Base: /api/integration-services/ar_gueno_cpf_service
• Regras: services.cpf.*
• In-list (availableCount=true): também retorna valores acumulados (totalAmount, valores por papel)
• Distinto da Central de Devedores BCRA

​

Relatório de entidade: risco vigente e screening AML explícitos

• riskSummary (novo): risco que o relatório apresenta como vigente. mode é manual, automatic ou not_evaluated. Com override manual ativo, effective traz o score manual, manual inclui justificativa, usuário, data e score anterior, e automatic.supersededByManual marca o score da matriz como histórico. Antes o relatório mostrava o score da matriz mesmo quando o operador havia definido o risco manualmente.
• amlScreening (novo): uma linha por fonte de listas com matchStatus, totalHits / relevantHits, listNames, reportedRiskLevel (valor bruto recebido, incluindo unknown quando é o valor retornado) e effectiveRiskLevel + riskLevelSource (nível derivado das correspondências quando necessário internamente). O PDF mostra o reportedRiskLevel quando existe.
• checks[]: passa a incluir screeningType, executionStatus (completed / failed), matchStatus e effectiveRiskLevel opcional. matchStatus pode ser undetermined: um check sem screening normalizado já não é apresentado como “No Match”.
• Impacto para integradores: os campos são aditivos e os existentes não mudam. Se você inferia “sem correspondências” a partir de checks[], leia amlScreening ou checks[].matchStatus e trate undetermined como inconclusivo.

​

Transações: comprimento do MCC relaxado

​

AML Crypto: paridade do fluxo do cliente

• Endpoints de execução respondem { success, data } com checkId opcional quando um snapshot é gravado.
• GET /aml-crypto/checks suporta filtros + paginação (total, limit, offset).
• GET /aml-crypto/checks/:id retorna um check por organização.
• Permissões: aml_crypto:read (histórico) e aml_crypto:execute (consultas).

​

POST /automations/from-template cria sempre desabilitada

• Impacto para integradores: após from-template, ative explicitamente com POST /automations/:id/toggle.
• Não há mudança em campos de request nem de response.

​

Modelo de automation: monitoramento de entidades (agendado)

• Novo modelo entity_monitoring_scheduled: cron → fetch_entities (filtros pré-configuráveis) → run_risk_matrix (matriz escolhida). Criada desabilitada.
• Knobs de pré-config: frequência/hora/fuso, builder de filtros, limite do listado, riskMatrixId.

​

Modelos de automation: pré-config + alerta → email

• GET /automations/templates pode incluir parameterDefinitions (path + mirrorPaths opcionais).
• POST /automations/from-template aceita paramValues opcional. Params obrigatórios ausentes → 400.
• Novo modelo alert_created_email_notify: em alert_created, envia email com send_push_notification (regras, severidades, destinatários, modelo). Criada desabilitada.

​

Presets editáveis + preview + CSV/PDF

​

Gerar relatório → async S3 + Downloads

• alerts_by_rules deixa de devolver um XLSX síncrono ou contentBase64 na resposta do run.
• A automation send_report / Gerar relatório prioriza reportPresetId; com sendEmail opcional (+ recipientEmails) também envia o arquivo por e-mail.
• Investigações, ficha da entidade (PDF) e Metrics Hub com delivery: "download" não retornam mais skipped por falta de destinatários: enfileiram o job e o arquivo fica em Descargables. Os relatórios de ficha e métricas aparecem com kind: "documents".

​

API de presets de relatórios

​

API de templates de relatórios

​

Automações por mudança de status de investigação

• Novas origens que disparam automações: avançar ou voltar de etapa (Em progresso ↔ Pendente de revisão e fechamento por etapa), reabertura de um caso fechado, ações de agente, a ação change_status / start_investigation de outra automação e o pipeline automático de resolução. Nenhuma delas emitia o evento antes, então automações sobre PENDING_REVIEW nunca rodavam.
• Não é mais emitido quando o status não muda: reenviar o status atual (por exemplo CLOSED em um caso já fechado) deixa de gerar notificações duplicadas.
• Status anterior no contexto: nova condição investigation.previousStatus e nova variável de template {{investigation.previousStatus}}, além de investigation.transitionSource para saber de onde veio a mudança.
• Novos templates de email de sistema por status: investigation_in_progress_email_*, investigation_pending_review_email_*, investigation_closed_email_* e investigation_reopened_email_* (es / en / pt).
• O seletor de status nas condições agora oferece os quatro status reais do fluxo, incluindo Pendente de revisão.

​

Novo status de entidade: not_started

• O padrão na criação continua under_review para não quebrar integrações existentes.
• Envie status: "not_started" no create (manual, automático ou bulk) para optar por ele.
• Rótulos da matriz e regras updateEntityStatus podem ir de not_started para under_review, active, rejected, blocked, etc. — não há passo intermediário obrigatório.
• Tabela completa e fluxos de exemplo: Visão geral — Status.

​

Delta e % de mudança totais (CBU+CVU) em metrics

• totalDelta — cbuDelta + cvuDelta
• totalPctChange — % sobre o estoque total no início (null se start = 0)
• totalAccountsStart / totalAccountsEnd — estoque CBU+CVU nos extremos da janela

​

autoExecuteIntegrations.enrichments é filtrado por país e tipo de entidade

• Vale para enrichments, enrichmentGroupRefs e executeAllActiveEnrichments, tanto na entidade principal quanto nas relacionadas (autoExecuteIntegrationsShareholders).
• Não muda a habilitação por organização, os bloqueios de integração nem as cadeias de fallback: aqui só se valida a cobertura de país / tipo de entidade.
• Impacto: requisições que misturavam códigos de outro país deixam de retornar esses provedores nos erros de enrichment. Todo provedor válido para o país da entidade se comporta exatamente como antes.

​

Criar notas no dossiê da entidade

• POST /entities/{id}/notes — body: content (obrigatório, máx. 8000), noteType opcional (general | analysis | finding | recommendation), isImportant opcional (boolean). Requer entities:edit (legacy entities:write).
• Cada nota guarda source: manual (UI) ou agent (HITL / agente contextual).
• Evento de auditoria note_added com source, noteType, noteId e conteúdo.
• GET /entities/{id}/notes sem alterações (lista, mais recentes primeiro).

​

Novo código de falha por linha: SCIENTIFIC_NOTATION_ID

• Campos verificados: externalId, originExternalId, destinationExternalId, originTaxId, destinationTaxId.
• A linha falha com o código SCIENTIFIC_NOTATION_ID em failures.csv / JSON failures[]; identifier_type lista os campos afetados.
• O comportamento segue batchErrorHandling como qualquer outra falha de linha (rollback_all aborta o arquivo, continue_collect_errors cria as válidas).
• Impacto: arquivos que antes importavam com ids corrompidos agora reportam essas linhas como falhas. Reexporte o CSV mantendo as colunas de id como texto.

​

Política de erros e artefatos S3 no batch de transações

• batchErrorHandling=rollback_all é o padrão (UI + upload multipart se omitido): aborta o arquivo com refs/amounts inválidos ou falhas de insert; o detalhe vai para failures.csv (S3), sem arrays gigantes em jsonb.
• O cliente pode escolher continue_collect_errors (pular linhas inválidas e criar as válidas) ou stop_keep_success.
• O seletor de política também está nos imports sem mapper (TX e entidades).
• CSV de falhas: colunas external_id,code,error,role,identifier_type,value.
• Novo GET /batch-import/jobs/{jobId}/payload: baixa o payload.json processado quando guardado (anexo autenticado).
• Alinhamento: jobs de user-events e entidades seguem o mesmo modelo S3-first das transações. O kind nas respostas é entity_batch; entity_automatic permanece como alias de entrada.

​

Filtro pela última avaliação de regras

​

Campos adicionais nos webhooks legacy planos de entidades

​

Relatório de linhas ignoradas em batch de transações

• Disponível para jobs executados com o default skipDuplicates=true; com skipDuplicates=false as duplicatas são resolvidas pelo banco e apenas contadas, então o endpoint retorna SKIPS_NOT_AVAILABLE.
• Jobs finalizados antes deste release não têm relatório salvo (SKIPS_NOT_AVAILABLE).
• Também disponível como botão de download no histórico de importações.

​

Relações declarativas com tax_id duplicado (bulk)

​

Vínculos a entidades existentes no create e na importação em massa

• POST /entities e POST /entities/automatic: body opcional relationships[] (máx. 10).
• Bulk CSV plataforma: colunas related_tax_id / related_external_id / related_entity_id, relationship_type, relationship_role, relationship_as_source (uma relação por linha).
• Se a contraparte não existir → RELATED_ENTITY_NOT_FOUND e a entidade não é criada.

​

security.member.environment_changed

• Evento: security.member.environment_changed
• context.fromAccess / context.toAccess: "both" | "production" | "sandbox" | "none"
• changes.environmentAccess: { previous, current } com os mesmos valores

​

Vínculo de entidades: soft-link sempre, default estrito do lote inalterado

• Default do lote (BC): omitir flags continua estrito — validateExistingEntity padrão true. Refs não resolvidas → 400 (igual a antes).
• linkEntityStrict=true: força hard-fail (body ou query).
• linkEntityStrict=false: força soft-link (não falha se faltar), mesmo se validateExistingEntity diga o contrário.
• validateExistingEntity=false: soft-link (e agora vincula se encontrar — antes o soft do lote pulava o link).

​

Código de erro: CREATION_CONTRACT_QUOTA_EXCEEDED

• Mesmo status HTTP e shape do payload (module, remainingTotal, periodKey, requested).
• Falhas de linha no bulk import emitem CREATION_CONTRACT_QUOTA_EXCEEDED; o código antigo permanece como alias depreciado para failures.csv históricos.

​

Unicidade de tax ID (por organização)

• Mesmo tipo já existe → a criação automática reutiliza essa entidade (alreadyExisted).
• Outro tipo já possui o tax ID → 409 com código DUPLICATE_TAX_ID (sem nova linha).
• Aplica-se a create manual, create automatic, PATCH de tax ID e restore de soft-delete.
• Duplicados históricos não são apagados; writes conflitantes novos são bloqueados na app e via trigger no banco.

​

Nova ação de regra: addFieldToCustomList

{
  "type": "addFieldToCustomList",
  "addFieldToCustomList": {
    "mappings": [
      { "fieldPath": "originTaxId", "listId": "uuid-lista-123" },
      { "fieldPath": "metadata.phone", "listId": "uuid-lista-456" }
    ],
    "reason": "Motivo opcional no item"
  }
}

​

Bloqueio na criação (configuração de análise de risco)

​

Endpoint dedicado para atributos

• mode: merge (padrão) — chaves enviadas sobrescrevem ou criam; omitidas são mantidas
• mode: replace — attributes do body substitui o mapa completo ({} limpa tudo)
• Buckets aninhados por categoria na escrita
• Dispara webhook entity.updated e matrizes com trigger entity_updated quando configurado

​

Atributos personalizados armazenados como enviados (API)

• Sem categoria: valores escalares/array na raiz (ex.: { "phone": "..." }) — inalterado.
• Categorizado: um objeto de primeiro nível agrupa suas chaves internas sob essa categoria (ex.: { "contact": { "phone": "..." } }). A chave do objeto é a categoria; no dashboard aparece como card de categoria.
• Leitura: GET retorna a mesma forma que foi escrita (sem achatar).
• Regras / webhooks: leem a forma armazenada — attributes.phone para plano, attributes.contact.phone para aninhado. Use chaves de categoria seguras como identificador.

​

Ativação operacional por país (merchant)

• GET /entities/{id}/country-activations — lista AR, BR, CL, CO, MX, US; linhas ausentes = deactivated (opt-in).
• PATCH /entities/{id}/country-activations/{countryCode} — body { "status": "deactivated" | "activation_requested" | "activation_in_progress" | "activated" }; requer entities:edit. Transições livres. Idempotente se o status não mudar (sem webhook).
• Webhook entity.country_activation_changed — emitido em cada mudança real; inclui activeCountryCodes, snapshot countries e timeline por país; inscrever-se na config de webhooks existente.

​

Import batch de eventos de usuário — política de erros por linha

• POST /batch-import/import/user-events aceita batchErrorHandling: continue_collect_errors (padrão), rollback_all ou stop_keep_success.
• Respostas 202 incluem preflightFailures quando linhas inválidas são ignoradas com política continue.
• POST /batch-import/validate-csv valida cada linha quando o target é user_event (rowErrors, validRowCount, invalidRowCount).

​

POST /rules — revisão IA síncrona em toda criação

• Regras novas ficam sempre em in_progress com enabled: false; status / enabled do body são ignorados no create.
• A resposta inclui aiReview e pode levar vários segundos.
• Body opcional creationProvenance: origem (user, agent, import_json, template, bundle, api) e ids de chat do agente.
• A revisão é auditada mas não debita tokens de IA.

​

security.member.invited / security.member.created — payload.context ampliado

• invitationId — correlacionar invited → created
• granularRoleIds, granularRoleIdsSandbox
• includeProduction, includeSandbox
• teamId, teamIdSandbox
• hasEnvironmentAccess — flag de acesso para a org do envelope
• environment — "production" ou "sandbox" conforme a org do envelope
• invitedByUserId, acceptedVia (em created)
• syncPartialFailure, syncErrorMessage (em created quando a configuração secundária não concluiu)

​

Polling de jobs batch import

​

Endpoints HTTP

• GET /batch-import/jobs/{jobId} — lookup direto por job id (entidades, transações e user events). Retorna status, contadores (totalItems, succeeded, failed, skipped), timestamps e jobFailure opcional se o job inteiro abortou. Query opcional include=failures retorna o mesmo JSON dos endpoints de failures por tipo.
• GET /batch-import/unified-history — novo query param jobId (correspondência exata; 0 ou 1 linha). O histórico unificado continua para listagens; use GET /batch-import/jobs/{jobId} para polling pós-upload.

​

Fluxo recomendado para integradores

​

Inteligência de Titulares CBU/CVU (ar_gueno_holder_intelligence_service)

​

Endpoints HTTP

• GET /api/integration-services/ar_gueno_holder_intelligence_service/health — disponibilidade e frescor do corpus (status, corpusFreshnessDate). Sem cobrança.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/exists — verificação no corpus. Retorna found e snapshotDate (null se não encontrado). Sempre HTTP 200 em sucesso (incluindo found: false). Sem cobrança.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/accounts-count — totais CBU/CVU + isNew e snapshotDate. Cobrável por request quando o produto tem preço.
• GET /api/integration-services/ar_gueno_holder_intelligence_service/cuits/:cuit/metrics — lookback densificado (lookback 1–180 ou preset window w_1d…w_180d). Query opcional date (YYYY-MM-DD, fim inclusive). Retorna aliases de estoque, deltas, %, variância e aceleração. Cobrável por request quando o produto tem preço. Erros: 400 LOOKBACK_REQUIRED / INVALID_LOOKBACK / INVALID_WINDOW / INVALID_DATE, 404 CUIT_NOT_FOUND, 422 INCOMPLETE_WINDOW / NO_INCREMENTAL_STATE.

​

Motor de regras

​

Documentação Serviços (en / es / pt)

​

Identificadores de entidade além de entityId

​

Criação (POST)

• POST /api/kyc/validations — body aceita entityId, entityExternalId ou entityTaxId (exatamente um).
• POST /api/kyc/biometric/sessions — mesmas opções.

​

Leitura (GET)

• GET /api/kyc/validations?entityTaxId=... ou ?entityExternalId=...
• GET /api/kyc/biometric/sessions?entityTaxId=... ou ?entityExternalId=...
• KYC: GET /api/kyc/entities/by-tax-id/:taxId/current|validations|status e rotas by-external-id
• Biométrico: GET /api/kyc/biometric/entities/by-tax-id/:taxId/current e by-external-id

​

Prévia sandbox (somente GET)

• GET /api/entities/by-tax-id/{taxId} e GET /api/entities?taxId=... podem retornar dados sintéticos sandboxMock: true (id: null) para números do catálogo sem linha real. Não habilita POST sem criar entidade real.

​

Respostas 409 aditivas para sessões / validações abertas

​

Biometria incorporada — POST /api/kyc/biometric/sessions

• Com a última sessão em pending ou in_progress, o create sempre retorna 409 ACTIVE_SESSION_EXISTS (nunca 201 com a mesma sessão pending).
• O body inclui activeSessionId para cancelar: POST .../sessions/{activeSessionId}/cancel.

​

Validação KYC — POST /api/kyc/validations

• Com validação aberta (pending, in_progress, in_review), o create retorna 409 VALIDATION_IN_PROGRESS.
• O body agora também inclui activeValidationId para cancelar: DELETE .../validations/{activeValidationId}/cancel.

​

includeRulesSummary no GET de uma transação

• includeRulesSummary=full — Adiciona persisted.rulesExecutionSummary da linha mais recente de risk_analysis_audits dessa transação. Regras não são reexecutadas na leitura.

​

Campos opcionais em rulesExecutionSummary

• rulesHit[].actions.originEntityStatus / destinationEntityStatus — configurados na regra que deu match.
• actionsExecuted.originEntityStatus / destinationEntityStatus — status finais de entidade aplicados na execução (junto com actionsExecuted.status para a transação).

​

Eventos security.member.* (nomenclatura unificada)

• Perfil / senha: security.member.profile_updated, .password_reset, .password_generated
• Equipes: security.member.team_added, .team_removed, .team_role_changed
• Canais (org filha): security.member.channel_granted, .channel_revoked
• Acesso a ambientes (production / sandbox): security.member.environment_granted, .environment_revoked — distinguidos por context.environment ("production" | "sandbox")

​

GET /api/kyc/biometric/entities/:entityId/current

• Retorna a última sessão biométrica da entidade (por createdAt), qualquer status (pending, in_progress, approved, rejected, …).
• 200 com null quando a entidade não tem sessões biométricas (não mais 404).
• Na listagem, currentSessionId continua sendo apenas a última sessão approved.

​

Eventos webhook de segurança (security.*)

• Auth: security.auth.login_succeeded, security.auth.logout, security.auth.login_failed
• Membros: security.member.invited, .created, .removed, .activated, .deactivated
• Perfis: security.role.created, .updated, .deleted, .assigned, .revoked
• RBAC: security.rbac.granular_toggled
• Senha (admin): security.member.password_reset, security.member.password_generated (antes security.user.password_*)
• Settings: security.settings.updated (sandbox, configurações de segurança auditadas)

​

Triggers granulares de matriz (watchFields)

​

Atualização de entidade — entity_updated ativo

​

Import bulk automático — enrichments nos filhos e escopo de monitoramento

• childEnrichmentPolicy: all_active (padrão), by_root_type ou basic_only.
  • by_root_type: linhas empresa → acionistas com todos os enrichments ativos exceto global_gueno_sanctions_enrichment; linhas pessoa → relacionadas só com dados básicos do provedor da raiz.
• monitoringApplyToRelationships: com false, monitoring só nas entidades principais. Padrão true com depth > 0 se omitido.

​

Eventos — campos de sessão do SDK e pré-login

​

Eventos — novos tipos

​

Novo endpoint — GET /sdk/config

​

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