Changelog da API

MUDANÇAS Toda mudança do contrato público, da mais recente para a mais antiga, classificada em quatro classes e nada além delas. O que define cada classe está na política de versão. Última mudança publicada: 2026-10-24. A API ainda não está em produção. Enquanto o primeiro ambiente produtivo não sobe, a data de cada item é o dia em que a mudança passou a fazer parte do contrato, e não o dia em que entrou no ar. A página de status mostra o mesmo fato pelo outro lado: não há medição sendo publicada ainda. Existe também o mesmo conteúdo legível por máquina em /docs/changelog.json, para você observar mudança sem raspar esta página. Mudança que quebra 25 Adição compatível 96 Correção 31 Depreciação 2

​

2026-10-24

2 mudanças Adição compatível Site público

​

Novo preço do cpf_status: R$ 2,50 por verificação

O módulo cpf_status passa a custar R$ 2,50 por verificação. O catálogo em /v1/pricing-catalog, a página de preços e o construtor de flows mostram o valor novo. Mudança que quebra API REST e webhook

​

cpf_status: o bloco data deixa de trazer mae e genero

A consulta do cpf_status passa a pedir à fonte só o que o módulo entrega: nome, nascimento, situação, óbito e o comprovante. As chaves mae e genero não vêm mais no bloco data. Nenhum outro módulo as entregava, e a Entrega Cadastral e a Coerência Cadastral continuam iguais.

​

2026-10-23

6 mudanças Adição compatível API REST e webhook

​

cnpj_registration: base pública da Receita, com reference_month, Simples e SIMEI

O cnpj_registration passa a responder pela base pública mensal da Receita Federal. O bloco company traz reference_month, o mês da base consultada, e os blocos simplesNacional e simei com a opção e as datas. Empresa aberta depois da base sai pendente, nunca como inexistente. O preço passa a R$ 0,50 por verificação. Adição compatível API REST e webhook

​

Gate de conta: eventos reward_claim e withdrawal

O bloco account_event aceita dois tipos novos, os dois sensíveis: reward_claim (resgate de bônus, indicação ou cupom) e withdrawal (saque ou retirada de saldo). Neles o gate confere a última detecção de múltiplas contas do titular: rosto duplicado entra em reasons como subject_face_duplicate, e titular sem essa detecção no histórico sai com face_uniqueness_unknown, nunca como rosto único. Adição compatível API REST e webhook

​

Novo módulo passive_liveness: prova de vida passiva com uma selfie

Uma selfie responde a prova de vida passiva e, quando o flow lê um documento, a comparação com o rosto dele. O bloco data traz status, liveness com evidence_level (sequence ou single_image), face, match e avisos de lista fechada. O módulo não pode estar no mesmo flow que face (422 passive_liveness_includes_face_match) e não substitui o liveness exigido por outros módulos. Adição compatível API REST e webhook

​

face: QR code do documento no widget e o campo type no resultado

No widget, a pessoa escolhe enviar a foto do documento ou o QR code do documento. O bloco data do módulo face passa a trazer type, com document_single_photo, document_front_back ou qr_code; o resto do bloco é o mesmo nos três caminhos. No caminho do QR, o cpf_ocr sai com os dados lidos do QR, no mesmo formato. Verificação anterior a esta data sai com type null. Adição compatível Site público

​

Novo preço do face: R$ 2,50 por verificação

O módulo face passa a custar R$ 2,50 por verificação, o mesmo valor pela foto do documento ou pelo QR code do documento. O catálogo em /v1/pricing-catalog, a página de preços e o construtor de flows mostram o valor novo; o formato da resposta não muda. Mudança que quebra API REST e webhook

​

Criar sessão com reference_id bloqueado passa a ser recusado com 422 reference_blocklisted

Quando o reference_id está na lista de bloqueio da conta, para o flow ou para a conta inteira, a criação da sessão responde 422 reference_blocklisted: a sessão não nasce, nada é cobrado e o titular não passa pela captura. Antes a sessão nascia e o bloqueio só vinha no envio, com o webhook verification.blocked. O bloqueio por documento ou por rosto continua no envio e na decisão, com o mesmo webhook. O resgate do link hospedado responde link_unavailable, e o flow com o módulo de evento de conta segue respondendo pelo veredito dele.

​

2026-10-18

14 mudanças Mudança que quebra API REST e webhook

​

SDKs de TypeScript, React Native e Python passam a 0.3.0

Os três SDKs sobem juntos para 0.3.0, a versão que acompanha os nomes em inglês do contrato registrados neste changelog (bloco data dos módulos, PLD/FT, custódia, assinatura, atestado e triagem). Na versão zero a mudança que quebra sobe o segundo número. A 1.0.0 sai junto com a publicação dos pacotes. Adição compatível Site público

​

Novo preço da leitura de documento: R$0,45 no cpf_ocr e no cnpj_ocr, R$ 0,42 no doc_global

Os três módulos de leitura de documento passam a ter o preço de uma leitura estruturada de duas páginas: cpf_ocr R$0,45, cnpj_ocr R$ 0,45 e doc_global R$ 0,42 por verificação. O catálogo em /v1/pricing-catalog, a página de preços e o construtor de flows mostram o valor novo; o formato da resposta não muda. Correção API REST e webhook

​

policy.allow_pep: afrouxar o PEP do flow pela sessão exige permissão no flow

Pedir policy.allow_pep igual a true num flow com allow_pep igual a false, na criação de sessão ou na emissão do link, passa a exigir que o flow tenha allow_pep_override_enabled ligado. Sem ele a resposta é 422 pep_override_not_enabled. Apertar a política pela sessão (allow_pep igual a false) continua livre. O campo nasce desligado, sai no detalhe do flow e só owner ou admin o mudam (403 insufficient_role para o dev). Na renovação e no resgate do link, o afrouxamento herdado só segue se a permissão ainda estiver ligada; senão vale a política do flow. Adição compatível API REST e webhook

​

pep_sanctions passa a consultar os inidôneos do TCU

A triagem de PEP e sanções inclui as empresas declaradas inidôneas pelo TCU para licitar (Lei 8.443/1992, art. 46), pelo CNPJ completo publicado pelo tribunal, atualizada todo dia. O hit sai com source tcu_inidoneos e list TCU. A lista é crítica: desligada, a resposta sai pending com critical_source_disabled; sem atualização além da janela de frescor (o endereço do tribunal fora do ar), pending com dataset_stale. Nos dois casos o módulo não é cobrado e a verificação vai para review. Mudança que quebra API REST e webhook

​

PEP, sanções e vedação de apostas: as chaves de details passam a ser em inglês

No hit do pep_sanctions, da triagem avulsa, da triagem de sócios e do changes do alerta do monitoramento contínuo (monitoring_aml), o details (os campos públicos da lista que explicam o hit forte por documento) troca funcao por function, orgao por agency, tipo por type, processo por process_number, fundamentacao por legal_basis, motivo por reason e fim_exercicio por exercise_end. Na restrição do betting_barred, o details troca orgao por agency, cargo por position, categoria por category e federacao por federation; uf não muda. A verificação gravada antes desta data passa a ler os nomes novos. Adição compatível API REST e webhook

​

pep_sanctions: coverage diz quais listas ficaram fora da consulta

O bloco data do check pep_sanctions e a resposta da triagem avulsa ganham coverage, com band (complete ou partial) e unavailable_sources, o id de cada lista desligada que não foi consultada. O aviso convive com approved: não baixa a nota e não é evidência contra o titular. null quando a triagem não chegou a consultar as listas (pending no check, unavailable na avulsa) e em verificação decidida antes do campo. Mudança que quebra API REST e webhook

​

Custódia, assinatura e atestado: formatos em inglês

A prova exportada da custódia sai no formato unifokal/custody-authorization@2, com o estado assinado em unifokal/custody-authorization-state@2, e a abertura do titular em unifokal/custody-authorization-subject@2. Evento gravado antes desta data segue com o tipo de antes e confere ao lado dos novos. O manifesto da assinatura avançada passa a unifokal/advanced-esignature@2, com v igual a 2; o dossiê assinado antes continua válido. O atestado de pessoa verificada usa o vct https://unifokal.com/vct/verified-person/v1, e as claims trazem liveness com result e date e legal_age com result e method igual a document. No webhook act.rejected, o kind do ato de presença é presence_confirmation. Os SDKs conferem os formatos novos. Adição compatível Painel

​

Aviso de mudança dos Termos com vigência de 30 dias na faixa do painel

Os avisos da faixa do painel ganham kind (notice ou terms_change), terms_version e effective_at. Uma mudança dos Termos sai como terms_change com a versão nova e a data em que ela passa a valer, sempre pelo menos 30 dias depois de o aviso entrar no ar, e o aviso fica no ar até essa data, que a faixa mostra. Adição compatível API REST e webhook

​

Alerta transacional: reference_role diz o que o reference_id identifica

O webhook do alerta do transaction_monitor ganha reference_role, logo depois do reference_id: subject quando ele identifica o titular, counterparty quando identifica a conta de destino e device quando identifica o aparelho. Ausente em toda outra verificação; presente também no modo minimal. Adição compatível API REST e webhook

​

identity_proven no webhook e o aviso identity_not_proven no flow

Todo webhook de verificação traz identity_proven, logo depois de data_purpose: true quando a verificação leu um documento de pessoa junto do face e do liveness, false quando conferiu o documento sem esse par. Criar ou editar um flow que lê documento de pessoa sem face e liveness juntos continua permitido, e a resposta traz warnings com o código identity_not_proven. Adição compatível API REST e webhook

​

Antecedentes, mandados e idade: o veredito sai aos 180 dias

Nos antecedentes criminais federal e estadual, nos mandados de prisão e na verificação de idade, o veredito sai aos 180 dias contados da verificação, como o texto publicado já dizia: o resumo checks diz expired, o bloco do módulo traz data.evidence_expired: true e o motivo da verificação que apontava o módulo passa a manual_review. Nos demais módulos de documento, rosto, prova de vida, listas, cadastro e crédito, o veredito fica e saem as medidas e os dados da pessoa; o match e os candidates do unique_face saem no mesmo prazo. O verification_id e o status não mudam. Correção API REST e webhook

​

Limiares, calibração, pontos por sinal, sombra e peso saem do payload, e o schema_version sobe para 3

Nenhum bloco de módulo traz mais limiar nosso, calibração, pontos por sinal, sombra ou peso. Saem face.threshold, liveness.threshold, doc_forensics.thresholds e o threshold de cada achado, registration_coherence.calibration, phone.reuse_window_days, fraud_network.window_days, fraud_network.thresholds e, de fraud_network.sync_burst, shadow, weight, window_minutes e min_subjects; de transaction sai contributions, e a evidence do transaction_monitor deixa de trazer a régua da regra que disparou. No topo do corpo, blocklist_face_match deixa de trazer threshold: a faixa segue em band e a força do casamento em similarity. Ficam a decisão, a faixa, o score e as razões como categoria. O schema_version do corpo do webhook passa a ser 3. Adição compatível API REST e webhook

​

Bloqueio por sócio cobra os módulos entregues

A verificação que termina em blocked com reason partner_blocklisted passa a cobrar os módulos que entregaram resultado antes do bloqueio, inclusive a leitura do documento e a consulta do quadro societário com a parcela por sócio, e não o resto. O bloqueio por documento e por reference_id continua sem cobrança, porque acontece antes de qualquer entrega. Adição compatível Painel

​

Consulta avulsa de CNPJ e sócios cobra por sócio, como a verificação

A consulta avulsa do módulo cnpj_partners passa a cobrar como a verificação: o preço do catálogo inclui o primeiro sócio, e cada sócio adicional devolvido soma o preço da unidade kyb_additional_partner, até o teto de sócios cobrados. O catálogo da consulta avulsa traz additional_partner_cents e max_billed_partners nessa linha, e o saldo exigido para abrir a consulta é o do teto. Documento não encontrado cobra só o primeiro sócio, e query.price_cents traz o valor que de fato saiu.

​

2026-10-17

10 mudanças Adição compatível API REST e webhook

​

Toda verificação perde a referência aos 180 dias; a identidade aprovada vale enquanto há atividade

A verificação de onboarding e a do monitoramento contínuo perdem a referência aos 180 dias contados da criação, como a dos gates e dos monitores já perdia: a consulta e a exportação trazem reference_id: null e a busca pela referência deixa de achar essa verificação; o verification_id e o resultado não mudam. O gate de conta, o gate transacional e o monitor transacional continuam reconhecendo o titular aprovado no onboarding por 180 dias contados da última aprovação e, depois disso, enquanto ele tiver histórico de conta ou de transação com você. Sem atividade por mais tempo, no_verified_identity e unverified_volume voltam a valer até um novo onboarding. Mudança que quebra API REST e webhook

​

Rede de fraude: as classes de evidência passam a ser em inglês

No check_details da API e do webhook, o bloco do fraud_network traz evidence_classes com local, contact e person. contato vira contact e pessoa vira person; local não muda. A verificação gravada antes desta data passa a ler os nomes novos. Correção API REST e webhook

​

PEP e listas restritivas: o schema publicado aceita pep null e evidence_expired

No schema ScreeningCheckData (openapi.json e os SDKs de TypeScript e Python), pep passa a ser booleano ou null e o bloco declara evidence_expired. É o que a API já manda desde 2026-10-17 no check pep_sanctions cuja evidência saiu, no prazo de 180 dias ou num apagamento a pedido: pep sai null e evidence_expired sai true. Nunca leia pep null como false. Adição compatível API REST e webhook

​

Resumo e bloco do módulo depois que a evidência sai: expired e evidence_expired

Quando a evidência de um módulo sai, no prazo de 180 dias ou num apagamento a pedido (de uma verificação ou por titular), o resumo checks passa a dizer expired no módulo cuja palavra dependia dela. Antes o resumo lia o que sobrou como se o dado nunca tivesse existido: device_intel saía clean, os seis módulos de crédito saíam pending, registration_data saía not_available, ubo_chain saía unavailable e doclink saía not_reused. No check_details, o módulo cuja evidência saiu traz data.evidence_expired: true, e todo campo que vinha dela sai null (a lista sai vazia), nunca false ou 0: o ofac_realtime não diz mais sanctioned: false, a mídia adversa has_adverse_media: false, a vedação de apostas is_restricted: false, e o pld_risk edd_required: false e measures_by_policy: false. Antes do prazo e sem apagamento nada muda. Trate expired como “a evidência saiu”, nunca como aprovação ou recusa: a decisão da verificação não muda. Correção API REST e webhook

​

Chave desconhecida no bloco esignature passa a responder 400 unknown_esignature_key

Na criação de sessão e na emissão de link, uma chave que o bloco esignature não conhece (só existe document_sha256) passa a ser recusada com 400 unknown_esignature_key, com a chave nomeada na mensagem, como a documentação e a OpenAPI já diziam. Antes a chave era descartada em silêncio e a sessão nascia. O código entra na lista de erros da OpenAPI e nos tipos dos SDKs TypeScript e Python. Mudança que quebra Site público

​

O feed do changelog e o manifesto de versão passam a ser em inglês

No feed /docs/changelog.json, a classe de cada entrada (quebra, compativel, correcao e depreciacao) vira breaking, compatible, fix e deprecation, e a área painel vira dashboard; os rótulos da página não mudam. O manifesto de versão (/api/version do site, /version da API e version.json do widget) troca a chave servico por service, com release e sha como antes. Mudança que quebra API REST e webhook

​

PLD/FT: o bloco pld_risk e o pacote selado do dossiê passam a ser em inglês

No check_details da API e do webhook, o bloco pld_risk troca os códigos para inglês. Fatores: pep_relacionado, sancao, servidor_publico, menor, capacidade_nao_declarada, beneficiario_final_nao_identificado e declaracao_do_cliente_alto viram related_pep, sanction, public_servant, minor, undeclared_capacity, ubo_not_identified e customer_declared_high. A origem do fator (verificacao, perfil_declarado e lista_gafi) vira verification, declared_profile e fatf_list, e o motivo do fator não avaliado (modulo_fora_do_flow, fonte_sem_resposta, perfil_nao_informado, lista_nao_carregada e nao_se_aplica_a_pessoa_natural) vira module_not_in_flow, source_without_response, profile_not_informed, list_not_loaded e not_applicable_to_natural_person. O pacote selado do dossiê de PLD/FT e da documentação de governança, exportado pelo painel, passa a unifokal/pld-dossier@2, com o conteúdo unifokal/pld-dossier-content@2 (v 2) e o bloco lists em inglês no lugar de listas. Os SDKs conferem o @2 e recusam o @1; o resultado da conferência não muda. O dossiê gravado antes continua dentro do pacote como foi gravado. No pacote de /v1/data-exports, o recorte pld traz as chaves em inglês: variant, items e basis no alerta, siscoaf_origin_number na decisão, coaf_number e authentication na retificação, e a política ganha format_version. Um evento criado antes desta data sai na reemissão com os nomes de antes. Mudança que quebra API REST e webhook

​

O bloco data de cada módulo passa a ser em inglês

Velho e novo, no check_details da API e do webhook. OFAC: sancionado, encontrados, resultado e lista_atualizada_em viram sanctioned, found_count, results e list_updated_at, e cada item traz name, type, list e programs. Antecedentes e mandados: nada_consta, nr_protocolo, mandados, antecedentes, listas, processos e parentes viram clear_record, protocol_number, warrants, criminal_records, lists, lawsuits e relatives; cobertura_uf vira uf_coverage. Inscrição estadual: uf_consultada, consultado_em, encontrada, habilitada, cobertura e inscricoes viram uf_queried, queried_at, found, enabled, coverage e registrations. Certidão trabalhista: situacao vira status (negative, positive ou positive_with_negative_effect), certidao vira certificate com number, issued_at e valid_until, e validade_dias vira validity_days. PGFN: o dossiê passa a source, official_source, document, reference_period, updated_at, coverage, principal, co_responsible e joint_liable, com listed, registration_count, total_amount_cents, filed_in_court_count, statuses, status_types, first_registration_date, last_registration_date e ledgers em cada bloco. Representante: consta_qsa_administracao, consta_qsa_sem_administracao e fora_do_qsa viram in_qsa_management, in_qsa_without_management e not_in_qsa. PJ estrangeira: encontrada, nao_encontrada_no_indice e candidatos viram found, not_found_in_index e candidates. Comprovante: cep_fora_da_base e uf_divergente viram cep_not_in_base e uf_mismatch. Dados cadastrais: finalidade vira stated_purpose e os campos retidos saem como affiliation, gender, address, contacts, companies e death_year. Prova de vida: os desfechos da captura e do volume saem como coherent, suspected, indeterminate, confirmed e plane. Antifraude: reasons_text e applied_rules trazem text no lugar de texto, e a family de cada regra em applied_rules sai em inglês (identity, network, velocity, behavior, phone, coherence e enrichment). Erros: unknown_assinatura_key, assinatura_signer_not_configured, assinatura_document_missing, assinatura_not_accepted, custodia_signer_not_configured e custodia_issue_failed viram unknown_esignature_key, esignature_signer_not_configured, esignature_document_missing, esignature_not_accepted, custody_signer_not_configured e custody_issue_failed. O conteúdo que a fonte devolve como ela é (o dossiê de crédito dos cinco módulos de bureau, o cadastro de CPF e de CNPJ, as listas e os processos dentro do bloco) não muda. Um evento criado antes desta data sai na reemissão com os nomes de antes. Adição compatível API REST e webhook

​

Monitores e perícia de documento: evidência por 180 dias e o campo evidence_expired

No session_monitor, no transaction_monitor e no doc_forensics a evidência fica disponível por 180 dias contados da verificação. Depois disso, a consulta pelo painel, a reemissão e a exportação trazem o veredito, a regra, o padrão, a severidade e os limiares, com a evidência vazia na forma de sempre (objeto ou lista vazios) e o campo novo evidence_expired: true (false antes do prazo, sempre presente). No mesmo prazo, a verificação dos gates conta e transacao e dos dois monitores perde a referência: a consulta e a exportação trazem reference_id: null e a busca pela referência deixa de achar essa verificação; o verification_id não muda. A sessão e o link perdem a referência e o contato aos 180 dias contados da verificação mais nova da sessão, ou da criação do link. Guarde no recebimento do webhook o que precisar guardar por mais tempo. Correção API REST e webhook

​

Corpo guardado do webhook e janela do atestado contados da verificação

O corpo guardado de cada evento da verificação sai aos 180 dias contados da verificação, inclusive o de uma entrega criada depois (antes contava da primeira gravação de cada entrega); depois disso, o replay e o reenvio pelo painel respondem payload_unavailable. O aviso de passkey, de dispositivo Pix e de apagamento continua com 180 dias contados da gravação. A janela de reemissão do atestado de humano verificado começa no dia da verificação, em UTC, e não no dia da decisão, então reissue_until nunca passa do prazo do corpo; a decisão que chega com a janela já fechada não emite e não cobra, com o motivo attestation_window_closed.

​

2026-10-16

1 mudança Correção API REST e webhook

​

A documentação passa a citar os blocos esignature e transaction_gate pelos nomes da API

A troca de nomes de 2026-10-14 chegou ao contrato, aos exemplos e aos tipos dos SDKs, mas parte do texto seguia com os nomes antigos: o bloco assinatura da criação de sessão e de link na seção da API, na página do módulo de assinatura e na tabela e no catálogo de erros; o bloco transacao da resposta 201 da ingestão na página do Gate Transacional e na documentação dos SDKs TypeScript e Python; e o módulo transacao nas descrições de transaction e transactions do OpenAPI. O texto agora diz esignature e transaction_gate, como a API. O contrato não muda: quem já envia esignature e lê transaction_gate não precisa fazer nada.

​

2026-10-15

1 mudança Mudança que quebra Widget

​

A opção do widget com o nome do documento a assinar passa a ser em inglês

Velho e novo: a opção assinaturaDocumentName do mount vira esignatureDocumentName, e o atributo data-assinatura-document-name da forma declarativa vira data-esignature-document-name. Continua sendo só o rótulo do documento na tela de aceite; o código do documento segue vindo do servidor. As classes CSS da tela de aceite passam de idsaas-w__assinatura para idsaas-w__esignature.

​

2026-10-14

6 mudanças Mudança que quebra API REST e webhook

​

Os valores de status, motivo e código passam a ser em inglês

Velho e novo, na API, no webhook e no widget: o código de motivo do titular aprovado vira approved, doc_ilegivel vira doc_unreadable, vida_nao_confirmada vira liveness_not_confirmed, selfie_nao_confere vira selfie_mismatch, sinal_de_manipulacao vira manipulation_signal, revisao_manual vira manual_review e erro_tecnico vira technical_error, e assim os demais do catálogo. Os erros assinatura_document_required, assinatura_not_supported e credit_consulente_unverified viram esignature_document_required, esignature_not_supported e credit_requester_unverified. O modo de execução do flow completo e expresso vira full e express; a finalidade do link verificacao e confirmacao vira verification e confirmation; a finalidade de crédito analise_risco_credito e concessao_credito vira credit_risk_analysis e credit_granting, e o vínculo mantem e pretende_manter vira existing e prospective. No PLD/FT, a classe de risco baixo, medio e alto vira low, medium e high, a severidade media, alta e critica vira medium, high e critical, o status do alerta e do caso aberto, em_analise e encerrado vira open, in_review e closed, e o regime coaf_geral_36 vira coaf_general_36. Na passkey do titular, o vínculo e a garantia (cadastro, presenca, identidade) viram registration, presence e identity; no pedido de confirmação, aberto, aprovado e expirado viram open, approved e expired. No atestado de humano verificado, as divulgações prova_de_vida, unica_no_servico e maioridade viram liveness, unique_in_service e legal_age. O significado de cada valor não muda. Mudança que quebra API REST e webhook

​

Os campos lidos dos documentos passam a ser em inglês

No check_details do cnpj_ocr, velho e novo: razao_social vira legal_name, nome_fantasia vira trade_name, tipo_documento vira document_type, situacao_cadastral vira registration_status, data_abertura vira opening_date e socios vira partners, com name, qualification e share em cada sócio. cnpj, nire e cnae_principal não mudam. Na identidade lida do documento de pessoa, document.naturalidade vira document.place_of_birth, e o tipo passaporte passa a sair como passport. Os demais campos da identidade já saíam em inglês e não mudam. Mudança que quebra API REST e webhook

​

As chaves do corpo da API e do webhook passam a ser em inglês

Velho e novo: o bloco assinatura do corpo da criação de sessão e de link vira esignature; o veredito transacao da resposta 201 da ingestão de transação vira transaction_gate; saldoUsado e saldoRestante do webhook viram usedBalance e remainingBalance; pep_in_carency do resultado de PEP vira pep_in_grace_period. O aceite do titular na tela de assinatura passa a ser POST /v1/verification-sessions/{id}/esignature/accept, o widget já chama o caminho novo. As rotas do painel passam a /v1/dashboard/operations/funnel, /v1/dashboard/operations/requests e /v1/dashboard/operations/caps, e as da detecção de múltiplas contas a /v1/unique-face/backfill e /v1/unique-face/duplicates. Os valores e o significado de cada campo não mudam. Adição compatível API REST e webhook

​

Triagem avulsa de PEP e sanções por documento, no painel e na API

Rota nova POST /v1/screening-checks: triagem de um CPF com o nome, ou de um CNPJ com a razão social, nas listas de PEP e de sanções, sem sessão de verificação. Exige uma chave criada com o escopo novo screening:write (chaves sem restrição não o têm) e com lista de IPs permitidos; Idempotency-Key opcional, e a repetição não cobra de novo. No painel, POST /v1/lookup-queries aceita module pep_sanctions com name, birth_date e uma das cinco finalidades da triagem; o catálogo traz kind e screening_purposes, e a trilha ganha channel, screening_result e actor_api_key_id. A resposta volta uma vez e não é gravada. Preço: a linha pep_sanctions. Adição compatível Painel

​

Passos condicionais com “ou”, teste no histórico e o porquê na verificação

module_conditions de POST /v1/flows e PATCH /v1/flows/{id} aceita a forma v2, com any de 2 a 4 alternativas e até 8 condições na regra; uma alternativa só volta como v1. O detalhe do flow traz module_condition_versions. Recusas novas: condition_value_out_of_range, condition_too_many_predicates, condition_too_many_groups e condition_fact_not_allowed (a aferição de idade não é sinal de regra). Rota nova POST /v1/flows/{id}/condition-preview, só com a sessão do painel, que testa a regra nas verificações do próprio flow e devolve só contagens. O detalhe da verificação no painel ganha conditional_steps. Um sinal sem resposta conclusiva continua pedindo o passo. Mudança que quebra API REST e webhook

​

Os nomes técnicos dos módulos passam a ser em inglês

A chave de cada módulo, em modules do flow, em module do check, em check_details do webhook, no catálogo de preços e nos motivos derivados (por exemplo <módulo>_below_threshold), passa a ser em inglês. Velho e novo: cpf_contatos vira cpf_contacts, cpf_enderecos vira cpf_addresses, cpf_receita vira cpf_status, cpf_empresas vira cpf_companies, cnpj_socios vira cnpj_partners, cnpj_cadastro vira cnpj_registration, cnpj_receita vira cnpj_realtime, cnpj_participacoes vira cnpj_shareholdings, idade vira age_assurance, face_unica vira unique_face, telefone vira phone, telefone_risco vira phone_risk, pep_sancoes vira pep_sanctions, credito_dividas vira credit_debts, credito_scr vira credit_scr, credito_boavista vira credit_boavista, credito_protestos vira credit_protests, credito_cadin vira credit_cadin, credito_pgfn vira credit_pgfn, antecedentes_cac vira criminal_records_federal, antecedentes_estaduais vira criminal_records_state, mandados_interpol vira warrants_interpol, pep_parentes vira pep_relatives, pep_lista_restritiva vira pep_restricted_lists, impedidos_apostar vira betting_barred, impedidos_vinculos vira betting_barred_relatives, coerencia_cadastral vira registration_coherence, midia_adversa vira adverse_media, dados_cadastrais vira registration_data, doc_forense vira doc_forensics, ubo_profundo vira ubo_chain, processos_judiciais vira lawsuits, transacao vira transaction_gate, beneficios_gov vira gov_benefits, sessao_monitor vira session_monitor, transacao_monitor vira transaction_monitor, pld_risco vira pld_risk, conta vira account_gate, assinatura vira esignature, endereco_ocr vira address_ocr, inscricao_estadual vira state_registration, custodia_autorizacao vira authorization_custody, representante_pj vira company_representative, atestado_humano vira human_attestation e kyb_estrangeira vira kyb_foreign. O source do pedido de step-up passa a ser transaction_gate ou account_gate. Os flows já criados seguem valendo com o nome novo, sem ação sua.

​

2026-10-11

3 mudanças Adição compatível Painel

​

Simular política: os bloqueios automáticos da lista entram na simulação

O candidato de POST /v1/decision-backtests passa a aceitar auto_deny_enabled e feedback_deny_enabled com o valor true, sozinhos: combinados com outro ajuste respondem 422 backtest_cascade_exclusive, e com false respondem 422 backtest_not_evaluable. A simulação refaz na ordem as verificações da conta no ambiente e a resposta da rodada traz o bloco cascade, com as entradas que nasceriam, as verificações barradas no flow e nos outros flows, as que ficaram fora da conta por motivo e se o resultado está completo. Adição compatível Painel

​

Simular política: o país esperado entra na simulação em produção

O candidato de POST /v1/decision-backtests passa a aceitar expected_country em produção, com o mesmo código de país do flow, e GET /v1/decision-backtests/evaluability exige environment (sandbox ou production) e, sem ele, responde 400. A simulação recalcula o sinal de país do IP nas verificações que guardaram o país, e cada verificação é simulada sozinha. No sandbox a verificação de IP e o antifraude são simulados pelo final do documento, então o pedido com expected_country responde 422 backtest_not_evaluable, com o motivo, e a tela Motor mostra o ajuste desligado. Adição compatível Painel

​

Pontos de atendimento declarados no painel

O painel ganhou os pontos de atendimento: um local da sua empresa, como loja, quiosque ou correspondente, declarado a partir de uma verificação aprovada feita nele, pela ação Declarar este local como ponto de atendimento no detalhe da verificação. Depois da declaração, a concentração de identidades no mesmo aparelho ou na mesma rede do local deixa de mandar sozinha toda verificação do ponto para revisão, e o ponto nunca dispensa a prova de identidade, a lista de bloqueio, a prova de vida nem a busca de rosto duplicado. Em Configurações, na tela de Segurança, a seção Pontos de atendimento mostra cada ponto com o volume do último mês, renova em lote, revoga e guarda a trilha. Declarar e renovar pedem o segundo fator e cabem ao proprietário ou ao administrador com a permissão nova Gerenciar pontos de atendimento. A verificação que chegou de um ponto mostra o rótulo dele no detalhe e na fila de revisão.

​

2026-10-10

1 mudança Correção API REST e webhook

​

Rotas da sessão do widget: o caminho leva self, e o id da sessão vai só no Authorization

As rotas autenticadas pelo id da sessão (por exemplo POST /v1/verification-sessions/self/monitor-events, POST /v1/verification-sessions/self/submit e GET /v1/verification-sessions/self/state) recebem self no lugar do id, e o id da sessão segue só no cabeçalho Authorization. Um caminho com o id da sessão responde 403 path_credential_retired, com a credencial da própria sessão ou com a de outra. O widget já chamava assim e não muda nada para quem só o embute. Quem envia os eventos do session_monitor pelo navegador ou chama o submit do sandbox pela API troca o id por self no caminho e confere a resposta de cada envio.

​

2026-10-09

1 mudança Adição compatível Painel

​

Simulações feitas pela UNIFOKAL aparecem marcadas no Motor

As respostas de /v1/decision-backtests passam a trazer origin, que diz quem pediu a simulação: member (a sua equipe, pelo painel), operation (a equipe da UNIFOKAL) ou republish (a simulação que roda sozinha quando o perfil do motor que você escolheu é recalibrado). A tela Motor marca as simulações feitas pela UNIFOKAL. Elas não ocupam a vez da sua equipe, que continua com uma simulação por vez em cada ambiente, e não contam no limite diário dela. Quando o perfil é recalibrado de novo, a simulação nova toma o lugar da que ainda rodava.

​

2026-10-08

2 mudanças Correção API REST e webhook

​

Gate de conta: acima do teto diário a prova de step-up não abre

O teto diário de gasto do módulo conta vale só para signup e recovery. Acima dele, o evento continua avaliado e não é cobrado, mas a sessão de prova não abre: decision.step_up sai com available false e reason step_up_rate_limited, e você aplica o seu próprio desafio. Os demais tipos (login, login_failed, password_change, email_change e sensitive_action) não entram em teto da casa e são sempre cobrados, menos login_failed, que é gratuito; para limitá-los, configure o orçamento da chave. Mande login só depois de a credencial conferir; a tentativa que falhou vai como login_failed. Correção API REST e webhook

​

Gates conta e transação: reenvio depois dos 180 dias responde payload_unavailable

Aos 180 dias contados da decisão, o corpo guardado das entregas dos gates conta e transacao sai junto com as razões. O replay (POST /v1/webhook-events/replay) e o reenvio pelo painel respondem payload_unavailable; a consulta pelo painel, a reemissão e a exportação trazem o veredito com reasons vazia e reasons_expired: true. A entrada de 2026-10-04 dizia que o reenvio trazia o corpo novo: o reenvio sempre manda o corpo exato que foi entregue, ou nada.

​

2026-10-07

10 mudanças Correção API REST e webhook

​

Motivo próprio quando o limite de uso da conta segura um módulo

Quando o limite de uso da conta é atingido, o módulo que depende de consulta paga fica pending com o motivo account_usage_limit, data null e fora da cobrança, em vez de gov_unavailable. O limite volta às 00:00 UTC. O mesmo motivo vale para a leitura de documento e para o ramo da cadeia societária em ubo_tree. O SDK ganhou a constante ACCOUNT_USAGE_LIMIT_REASON. Adição compatível API REST e webhook

​

Sua base de clientes à venda, com o cadastro do endereço no painel

O módulo client_source passa a ser vendável a 10 centavos por resposta entregue (sem resposta e resposta fora do combinado não são cobradas). O endereço que a UNIFOKAL consulta é cadastrado no painel, em Base de clientes, um por ambiente, com o segredo srcsec_ exibido uma vez, troca de segredo, teste ao vivo e o aviso de quando as consultas foram pausadas por falhas seguidas. O flow com client_source precisa de liveness ou face junto; sem eles, POST /v1/flows e PATCH /v1/flows/{id} respondem 422 module_dependency_violation. Correção API REST e webhook

​

Gate de conta: acima do teto diário do módulo o evento é avaliado e não é cobrado

Quando o teto diário de gasto do módulo conta é atingido (o teto conta só signup e recovery), o evento continua avaliado (veredito, verificação e webhook) e não é cobrado. O motivo gate_budget_exceeded passa a significar só que o orçamento que você configurou para a chave acabou: o evento não foi avaliado, e a integração deve falhar fechado. Adição compatível API REST e webhook

​

Listas sobre a pessoa só com a identidade comprovada: motivo identity_not_proven

pep_sanctions, betting_barred, adverse_media e os módulos de antecedentes, sanções e vínculos só consultam a lista quando a verificação comprova que a pessoa presente é a dona do documento. Sem essa prova o módulo sai pending e não é cobrado; em pep_sanctions, betting_barred, adverse_media, pep_relatives e betting_barred_relatives o data.reason vem identity_not_proven. Com pending, pep, flagged e os demais campos do data não afirmam nada. Quando a verificação é aprovada manualmente no painel, pep_sanctions, betting_barred e adverse_media rodam na aprovação e são cobrados pelo preço de sempre; se a resposta pedir análise, a verificação vai para review com o resultado, e o webhook sai com esse status. Correção API REST e webhook

​

Antifraude: applied_rules lista só as regras que contribuíram, sem peso

No fraud_assessment, no webhook, na API e no painel, applied_rules passa a listar só as regras que contribuíram para o fraud_score, as mesmas de reasons, cada uma com code, family e texto. O campo weight de cada regra e o campo families saem sempre null. As chaves continuam as mesmas. Correção API REST e webhook

​

Dado pessoal recusado no reference_id da sessão, do link e dos lotes

POST /v1/verification-sessions e POST /v1/verification-links, pela chave e pelo painel, recusam com 422 pii_shaped_value um reference_id com forma de dado pessoal (CPF, CNPJ, telefone ou e-mail), sem o valor no corpo da resposta, como a ingestão de transação já fazia. O bloqueio por referência digitada no painel segue a mesma regra, e os lotes de links e de consultas recusam o arquivo com link_batch_pii_shaped_reference e lookup_batch_pii_shaped_reference, com o número da linha. Telefone escrito com o prefixo de discagem de longa distância também passa a ser recusado no reference_id e, na ingestão, no counterparty_ref e no instrument.ref. É o que o contrato já dizia: nunca coloque dado pessoal nesses campos. Use o id do usuário no seu sistema; um UUID serve. Mudança que quebra API REST e webhook

​

reference_id da sessão e do link com o conjunto de caracteres da ingestão

O reference_id de POST /v1/verification-sessions e de POST /v1/verification-links passa a aceitar de 1 a 255 caracteres entre letras, dígitos e . _ : @ -, sem começar por - nem @, o mesmo conjunto que a ingestão de transação já exigia. Espaço nas pontas continua aparado; espaço no meio, caractere invisível, de largura plena ou fora do conjunto é 422 reference_id_charset, sem criar sessão nem link. A renovação da sessão e a abertura do link herdam a referência e não mudam. Adição compatível API REST e webhook

​

UUID aceito como reference_id na ingestão e nos ids de evento

Na ingestão de transação, o reference_id passa a aceitar um UUID, o id de usuário que muitos sistemas já usam. Os ids de evento (external_id, settles, act.external_id e account_event.external_id) também passam a aceitar UUID, e a numeração do seu sistema deixa de ser recusada por coincidência. Esses ids continuam sendo do seu sistema e nunca levam dado pessoal; no counterparty_ref e no instrument.ref, um UUID seu vai com prefixo ou como HMAC. Adição compatível API REST e webhook

​

Webhook: data_purpose sempre presente e o método da aferição de idade

O data do webhook passa a trazer data_purpose, a finalidade do dado declarada no flow: identity ou age_assurance. O campo vem sempre, também no modo enxuto. Na aferição de idade vêm ainda age_risk_tier (high ou moderate) e age_method (facial_estimation, document, manual_review ou null), o método que decidiu a idade, para o seu registro de auditoria. A criação da sessão ganha dois códigos: 422 age_contest_channel_required (flow com idade em produção sem o atendimento ligado, o canal de contestação) e 503 age_document_path_unavailable (o caminho de documento da aferição indisponível no momento). Adição compatível API REST e webhook

​

GET /v1/webhook-events: paginação por cursor

A listagem de eventos não confirmados aceita o parâmetro opcional cursor e devolve next_cursor. Sem cursor, a resposta é a de sempre (page, totalPages e totalItems), com next_cursor quando há mais. Com cursor, a página continua de onde a anterior parou, sem contagem e sem repetir evento quando chegam falhas novas, e a resposta traz data, next_cursor e has_more (o conteúdo do cursor é opaco e não é contrato). O teto continua 20 por página. Cursor que não veio desta rota é 400 invalid_cursor. Para varrer a lista inteira, prefira o cursor.

​

2026-10-04

9 mudanças Adição compatível API REST e webhook

​

Gates conta e transação: razões por 180 dias e o campo reasons_expired

No transacao, reasons e contributions ficam disponíveis por 180 dias contados da decisão. Depois disso, a consulta pelo painel, a reemissão e a exportação trazem o veredito, o risco, a confiança e as versões, com reasons e contributions vazias e o campo novo reasons_expired: true (false antes do prazo, sempre presente). No conta vale o mesmo para reasons, e type e step_up_session_id continuam no bloco; os dois passam a vir preenchidos. Guarde no recebimento do webhook o que precisar guardar por mais tempo, inclusive para a avaliação anual de efetividade, se o seu regime a pede. Adição compatível API REST e webhook

​

doc_forensics: laudo dos três documentos em data.documents[]

O módulo doc_forensics passa a periciar, além do documento de identidade, o documento da empresa e o comprovante de endereço que o fluxo já capturou, num laudo só e sem pedir arquivo novo. data.verdict é o resultado combinado: revisão se qualquer documento pedir revisão. A chave nova data.documents[] traz o laudo de cada documento, com document, verdict, media_type, bands, evidence, findings, regions e measurable_facets. O módulo também entra num fluxo só de empresa, com cnpj_ocr no lugar de cpf_ocr. Nenhum campo existente muda de forma. Correção API REST e webhook

​

Antifraude sem informação suficiente deixa de contar a favor da aprovação

Quando a análise antifraude não reúne informação suficiente para afirmar, ela deixa de contar a favor da aprovação da verificação: fica fora da decisão, nem para aprovar nem para reprovar, e em alguns casos a verificação segue para revisão sem cobrança. Correção API REST e webhook

​

Antifraude: o bloco coverage traz só band e sufficient, e o schema_version sobe para 2

O bloco coverage do fraud_assessment passa a trazer só band e sufficient, no webhook e no painel. Os campos measured, total, pct, min_pct e families saem do bloco, e o schema_version do corpo do webhook passa a ser 2. Adição compatível API REST e webhook

​

Antifraude: o bloco coverage passa a trazer a faixa da análise

O bloco coverage do fraud_assessment passa a trazer band: complete, partial ou insufficient. sufficient continua e é false só em insufficient. Adição compatível Painel

​

PLD/FT: nova situação monitorada de identificação

O monitoramento de PLD/FT passa a selecionar para a sua análise uma situação de identificação de cliente prevista na Carta Circular BCB 4.001/2020, art. 1, III, b. A seleção roda só com a regra confirmada na sua política, abre caso como as demais e entra no dossiê, que passa ao formato aml-dossier-3 com um bloco a mais. Nada muda para o titular e nenhum webhook novo é enviado. Mudança que quebra API REST e webhook

​

Face Match exige documento no flow, e o cadastro de aparelho Pix aceita a reautenticação facial

O módulo face passa a exigir um documento no mesmo flow, cpf_ocr ou doc_global: é dele que sai a foto contra a qual a selfie é comparada, e sem ele a verificação nunca chegava a uma decisão. POST /v1/flows e PATCH /v1/flows/{id} respondem 422 module_dependency_violation com face sem documento, e POST /v1/verification-sessions e POST /v1/verification-links respondem o mesmo código para um flow antigo montado assim, sem criar sessão nem link. O pix_device passa a exigir liveness e uma de duas formas do 1:1: face_reauth, a preferida, contra a matrícula da conta e sem documento, ou face, contra o documento do mesmo flow. O catálogo publica a regra em requires_any_of, e os SDKs TypeScript e Python conhecem o código na criação de sessão e de link. Adição compatível Painel

​

Chave revogada pela UNIFOKAL: aviso no painel e campos novos em GET /v1/keys

Se uma chave aparecer fora do seu servidor, for usada sem a sua autorização ou um administrador da conta pedir, a UNIFOKAL pode revogá-la na hora (Termos, item 3.4) e avisa por e-mail os owners e admins. GET /v1/keys passa a trazer revoked_at, revoked_by_unifokal e staff_revocation_reason (credential_leak, unauthorized_use ou client_request), e a tela Chaves mostra por 30 dias uma faixa com a chave, a data e o motivo. A chave revogada continua respondendo 401 invalid_api_key; só a frase do message ficou neutra, sem dizer quem revogou. Adição compatível API REST e webhook

​

Consulta cadastral refeita sozinha quando a fonte cai

Quando a fonte cadastral não responde, o check do tier continua pending com gov_unavailable, data null e fora da cobrança. Agora a consulta é refeita sozinha por tempo limitado depois da decisão: se a fonte voltar, sai um webhook novo da mesma verificação, com revision, trazendo o dado no check e sem cobrança a mais. Quem já faz upsert pelo id do evento não precisa mudar nada.

​

2026-10-03

4 mudanças Adição compatível Painel

​

Recarga automática com limite diário, limite por cobrança e pausa

A recarga automática passa a fazer no máximo 3 cobranças a cada 24 horas e até R$ 10.000,00 por cobrança, e o formulário mostra os dois limites. Ela pausa depois de duas recusas seguidas, na primeira recusa de cartão vencido ou inválido e quando uma cobrança é contestada. O painel mostra a pausa com o que fazer para retomar, e quem administra a conta recebe um e-mail a cada recusa e a cada pausa. Correção Widget

​

Widget: a mídia sobe só pelo formulário assinado

O widget passa a enviar foto e documento ao armazenamento só pelo formulário assinado que acompanha cada envio. Navegador sem suporte a FormData recebe um erro explícito, com a frase pedindo para atualizar ou trocar o navegador, em vez de seguir por outro caminho. Quem usa o widget pelo script ou pelo pacote não precisa mudar nada. Correção API REST e webhook

​

Telefone recusado em reference_id, counterparty_ref e instrument.ref

Na ingestão de transação, reference_id, counterparty_ref e instrument.ref recusam número de telefone, com ou sem máscara, com 422 pii_shaped_value, sem o valor no corpo da resposta. É o que a documentação do transacao já dizia: número de pessoa nunca é referência. Use um id do seu sistema ou, no instrument.ref, o token que o seu PSP devolve ou um HMAC. Adição compatível API REST e webhook

​

Corpo do evento por destino: completo ou enxuto

POST /v1/dashboard/webhook-endpoints aceita payload_mode, full ou minimal, e sem ele o destino nasce full, o corpo de sempre. PATCH /v1/dashboard/webhook-endpoints/{id}/payload-mode troca o corpo de um destino já cadastrado, só pelo painel e com papel de dono ou administrador. A lista de destinos traz payload_mode de cada um. O minimal leva identificadores, decisão, motivo, saldos e o resumo checks, sem check_details e sem dado do titular; o detalhe fica no painel. A troca vale para os eventos montados depois dela: retentativa, reenvio e replay repetem o corpo já montado.

​

2026-10-02

5 mudanças Adição compatível API REST e webhook

​

Motivo novo cadastral_source_unavailable: consulta cadastral fora segura a aprovação

Quando a consulta cadastral de um fluxo não responde na análise, e uma checagem da decisão depende do dado dela, a verificação que seria aprovada vai para revisão humana com o motivo novo cadastral_source_unavailable em decision_reason. Recusa e bloqueio não mudam. Para o titular o código é revisao_manual. Reprocessar a verificação no painel refaz só a consulta que faltou. Correção API REST e webhook

​

Proteção de conta à venda, com o flow exclusivo

O módulo conta passa a ser vendável a 5 centavos por evento avaliado. POST /v1/flows e PATCH /v1/flows/{id} respondem 422 account_gate_module_exclusive quando o conta aparece junto de qualquer outro módulo: o evento é decidido dentro da criação da sessão, sem passo de captura, e a composição mista terminava sempre em revisão. Mantenha o seu KYC no flow que você já tem e crie um flow só com o conta; a prova a mais mora no flow que step_up_flow_id aponta. POST /v1/verification-links recusa o flow com conta com 422 account_event_required, porque o link não leva o evento. Adição compatível API REST e webhook

​

Passkey: data.passkey_binding no webhook do flow que vincula a chave

A verificação de um flow com passkey_bind traz data.passkey_binding, também no modo minimal. Com bound true, passkey_id é a chave criada na sessão e vinculada por esta verificação, o mesmo id do evento passkey.bound. Com bound false, reason diz por que não vinculou: verification_not_approved, not_registered (a pessoa não criou a chave, por exemplo porque a janela da confirmação não abriu e ela seguiu sem a passkey) ou not_eligible. No widget, a espera pela janela da confirmação ganhou a saída para quem não conseguiu abrir: tentar de novo ou seguir sem a passkey. Seguir sem ela nunca aprova um ato. Os SDKs TypeScript e Python conhecem o campo. Mudança que quebra API REST e webhook

​

Gate de conta: account_event.external_id obrigatório e o step-up com prova de humano

POST /v1/verification-sessions com o bloco account_event passa a exigir external_id, o identificador único do evento no seu sistema (1 a 255 caracteres opacos, sem dado pessoal). Ele vira a chave de idempotência do evento no lugar do reference_id: o mesmo external_id em até 600 segundos devolve a mesma resposta, e outro evento do mesmo titular é sempre avaliado. Com step_up_flow_id no flow e veredito step_up, decision.step_up passa a trazer a sessão de prova (session_id, expires_at e factor) ou o motivo em reason, inclusive gate_budget_exceeded quando o teto diário do módulo foi atingido. Sem step-up configurado, decision.step_up continua igual. Os SDKs TypeScript e Python acompanham. Correção API REST e webhook

​

return_url: destino https só com o host na lista do ambiente

A criação de sessão confere o host de um return_url https contra a lista de destinos de retorno do ambiente, que você mantém no painel, em Organização. A comparação é pelo host exato, em minúsculas e com domínio internacional na forma punycode, a porta 443 vale como ausente, e o curinga *.seudominio.com.br cobre um nível só, nunca o próprio domínio. Host fora da lista responde 400 return_url_not_allowed. Sem lista no ambiente, a sessão é criada e o titular termina na tela de conclusão, sem redirecionamento. A lista de cada organização nasceu com os hosts usados nos últimos 30 dias, e o painel avisa até ela ser revista. O esquema próprio do seu aplicativo não tem host a comparar e não depende da lista.

​

2026-10-01

1 mudança Adição compatível API REST e webhook

​

OFAC: ofac_realtime à venda, com a data da publicação da lista

O módulo ofac_realtime pode ser ligado num flow. Ele confere o nome e o CPF lidos do documento na lista OFAC SDN, na versão vigente publicada pelo Tesouro dos Estados Unidos, e o check traz o campo novo publicacao_em, a data dessa publicação, ao lado de lista_atualizada_em. Cada item de resultado traz uid, nome, tipo, lista e programas da entrada e as medidas do casamento (matched_by, strong, similarity, precision, listed_at). Enquanto a versão vigente da lista não puder ser confirmada, o check fica pending e não é cobrado.

​

2026-09-29

1 mudança Adição compatível API REST e webhook

​

PLD/FT: transfer e payment seguem a direction da ingestão

No monitoramento de PLD/FT, uma transfer ou um payment com direction in conta como entrada na conta do titular, e com direction out, como saída. Sem direction, os dois continuam contando como saída, como antes. Os outros tipos têm direção própria e o type prevalece: um deposit é sempre entrada, mesmo com direction out. Mande direction nas transferências que o seu cliente recebe, para que as regras de PLD/FT e o rascunho da comunicação leiam cada valor do lado certo.

​

2026-09-28

1 mudança Adição compatível API REST e webhook

​

Prova de humano: recusas do ato no contrato, data.attestation e o step-up nos SDKs

A criação de sessão lista as recusas que o bloco act e a passkey já davam: act_requires_passkey, passkey_not_enrolled, passkey_bind_needs_authentication, passkey_bind_needs_reproof, act_hostile_char, act_kind_invalid, act_summary_invalid, act_counterparty_invalid, act_amount_invalid e act_currency_invalid; a emissão do link lista as seis do ato, reference_id_charset e pii_shaped_value. Chave desconhecida no bloco act passa a responder 400 unknown_act_key, como já estava publicado, em vez de validation_error. Na sessão com ato, a chave de idempotência é o act.external_id na forma canônica, a mesma que fica carimbada: o mesmo ato com caractere invisível ou espaço nas pontas não abre uma segunda sessão. O verification.completed de um flow com human_attestation documenta data.attestation, com issued, sd_jwt no formato dc+sd-jwt e o motivo quando não há emissão. Os SDKs TypeScript e Python conhecem data.attestation, os novos códigos e o step_up da resposta de ingestão, com session_id, expires_at, factor e reason.

​

2026-09-27

5 mudanças Adição compatível API REST e webhook

​

Step-up com prova de humano: data.step_up_of no webhook da sessão de prova

O verification.completed da sessão de prova que o gate transacao abriu traz data.step_up_of, também no modo minimal, com source (o gate que pediu a prova), verification_id (a verificação do pagamento) e event_type (o tipo do evento). É por ele que você liga o desfecho da prova ao pagamento que estava esperando. A verificação do pagamento não muda por causa da prova, e toda outra verificação sai como antes. Os SDKs TypeScript e Python conhecem o campo. Adição compatível API REST e webhook

​

Comprovante de endereço ganha cep_consistency

No módulo address_ocr, o data do check ganha cep_consistency: o CEP lido do comprovante conferido contra uma base de endereços, com ok (o CEP está na base, na mesma UF), uf_divergente (está na base, em outra UF), cep_fora_da_base ou unknown (não houve conferência). Fora da base não quer dizer inexistente. É informação para a sua política e nunca muda o desfecho da verificação. Adição compatível API REST e webhook

​

Monitoramento transacional: alerta grave nunca retido, com billing.waived

O alerta de severidade alta do transaction_monitor nunca é retido por volume nem por falta de saldo. Quando ele sai acima do volume contratado ou sem saldo, chega sem cobrança, e o data do webhook traz billing com waived igual a above_volume ou no_credit. Alerta cobrado normalmente não traz o bloco. Os SDKs TypeScript e Python conhecem o campo. Adição compatível API REST e webhook

​

PEP e sanções: resumo pronto no check e cota diária do módulo

O bloco data do check pep_sanctions ganha pep_status (função em exercício e saída da função no último ano, em três ou em cinco anos, com o cargo como a fonte publica só no casamento por documento) e, em aggregates, is_pep, has_sanctions_br, has_sanctions_intl, worst_severity e as janelas separadas sanction_windows e pep_windows. windows continua no payload como a soma das duas, marcado como depreciado. Cada hit de PEP traz exercise_end, o fim do exercício da função, e pep_in_grace_period passa a contar dele: antes contava do fim da carência e marcava o contrário. Programe contra hits[].source, o identificador estável da lista. A criação de sessão em produção pode recusar com 429 module_quota_reached quando a cota diária do módulo da organização acaba, com Retry-After até a meia-noite UTC; a renovação de uma sessão não conta. Adição compatível API REST e webhook

​

PLD/FT: pld_profile aceita net_worth_cents e declared_at

O bloco opcional pld_profile, na criação de sessão e na ingestão, aceita net_worth_cents, o patrimônio declarado pelo seu cliente em centavos, com o mesmo teto da capacidade financeira, e declared_at, a data AAAA-MM-DD em que ele fez a declaração. Sem declared_at vale a data do recebimento; data no futuro é recusada com 422 pld_profile_invalid, com o campo na mensagem e nunca o valor. Cada declaração recebida fica registrada com a data, o recebimento e a chave que a enviou, e sai na exportação de dados da conta. Os SDKs TypeScript e Python conhecem os campos.

​

2026-09-26

10 mudanças Adição compatível API REST e webhook

​

Passkey: eventos passkey.bound, passkey.revoked e act.rejected, e o step_up do gate transacional

Módulo novo passkey, com a venda pausada (Em breve). O webhook ganha três tipos de evento: passkey.bound (a chave passou a valer para o titular), passkey.revoked (a chave deixou de valer, inclusive pelo painel e no apagamento) e act.rejected (o titular disse que não reconhece o pedido). Os dois da chave chegam no webhook do flow da verificação que a vinculou, e o act.rejected no da sessão de prova, com corpo mínimo, a mesma assinatura e o mesmo replay. No gate transacional, quando o flow configura o step-up e o veredito é step_up, a resposta traz o bloco step_up: com available true, session_id é a sessão de prova (monte o widget com ela), válida por 600 segundos, e factor diz o fator (passkey, face_reauth ou os dois); com available false, reason diz por quê e você aplica o seu próprio desafio. O resultado da prova chega no webhook da sessão de prova. Adição compatível API REST e webhook

​

Atestado de pessoa verificada: data.attestation no webhook e o metadado do emissor

Módulo novo human_attestation, com a venda pausada (Em breve). O webhook ganha data.attestation, também no modo minimal, com issued e, quando emitido, id, format (dc+sd-jwt), sd_jwt (o SD-JWT VC compacto), vct, kid, issued_at, expires_at e disclosable (as informações que podem ser mostradas em separado: sub, prova_de_vida, unica_no_servico e maioridade). O bloco do módulo em check_details traz os mesmos dados sem o token. Não emitido traz reason: verification_not_approved, manual_decision, attestation_sandbox_not_issued, attestation_signer_not_configured, liveness_not_approved ou attestation_issue_failed. As chaves públicas de produção ficam em https://unifokal.com/.well-known/jwt-vc-issuer e nos SDKs (verifyHumanAttestation e presentHumanAttestation no TypeScript, verify_human_attestation e present_human_attestation no Python). O painel ganha POST /v1/dashboard/verifications/{id}/attestation/reissue, que devolve uma emissão nova do mesmo atestado, com os erros attestation_not_issued e attestation_signer_not_configured. Adição compatível API REST e webhook

​

Confirmação fora de banda: o link com purpose confirmation e o ato

POST /v1/verification-links aceita purpose (verification, o padrão, ou confirmation) e o bloco act (kind, summary, amount_cents, currency, counterparty e external_id, este obrigatório pela API). O link de confirmação vale no máximo 600 segundos, exige um flow com passkey ou face_reauth e a pessoa com o fator, fica um aberto por pessoa (o novo revoga o anterior) e tem teto de cinco por pessoa por hora. A view do link ganha purpose, act_kind e act_digest, e o painel lê o estado ao vivo por GET /v1/verification-links/{id}. O resgate devolve purpose igual a confirmation, e verification.completed ganha data.purpose e data.act com kind, digest e external_id, o mesmo digest da criação. Códigos novos: act_required, act_not_accepted, act_external_id_required, act_hostile_char, act_kind_invalid, act_summary_invalid, act_counterparty_invalid, act_amount_invalid, act_currency_invalid, unknown_act_key, expires_in_too_long_for_confirmation, confirmation_requires_human_proof, no_factor_enrolled, confirmation_rate_limited e confirmation_unavailable; e o link comum passa a recusar na emissão, com os códigos da criação de sessão, o flow de passkey que o resgate recusaria (passkey_not_enrolled, passkey_bind_needs_authentication e passkey_bind_needs_reproof). Adição compatível API REST e webhook

​

Criação de sessão: 429 attempt_limit_reached para tentativas repetidas da mesma referência

A criação de sessão pode recusar com 429 attempt_limit_reached quando a mesma referência já tentou vezes demais num período recente. A recusa não traz Retry-After, não cria sessão e não cobra. Não repita automaticamente: trate como fim da tentativa daquela pessoa e siga pelo seu atendimento. Os SDKs oficiais já tratam o código como teto que não se repete. Adição compatível API REST e webhook

​

Novo no sandbox: a resposta parcial do cadastro de CNPJ

No sandbox, o CNPJ de teste terminado em 84 simula a base que responde sem os dados da empresa nos módulos cnpj_partners, cnpj_registration, cnpj_realtime e cnpj_shareholdings. O módulo aprova e o item de check_details sai com data.company null e completeness partial, o mesmo formato que a produção entrega quando a resposta vem incompleta. Depreciação Widget

​

A handoff_url passa a levar o token no fragmento da URL

A handoff_url devolvida por POST /v1/verification-sessions/{id}/handoff e o QR que o widget mostra passam a levar os parâmetros t e b depois de # (h.html#t=ho_…&b=…), e não mais depois de ?. O navegador não envia o fragmento ao servidor nem o coloca no Referer, então o token de uso único deixa de passar por log e proxy no caminho. Abra a URL como ela chega, sem remontar. A forma antiga (h.html?t=ho_…) continua aceita até a data de saída e, nesse período, a página responde com os cabeçalhos Deprecation e Sunset. O SDK React Native já lê as duas formas. Sai do ar em 2026-12-31. Adição compatível Painel

​

Consulta em lote por planilha, com resultado por arquivo

A consulta avulsa do painel ganha a aba Em lote: um CSV com reference_id,document roda uma consulta por linha, com o mesmo preço, a mesma finalidade e os mesmos limites diários da consulta de um documento. O arquivo só entra se couber no que resta do dia (429 com o código da consulta avulsa) e no saldo (402 insufficient_credit), e o envio pede o segundo fator. O resultado sai num CSV por link de 5 minutos, uma vez, e a guarda de fórmula de todo CSV do painel passa a cobrir também a quebra de linha no começo da célula. Adição compatível API REST e webhook

​

Comprovante de endereço ganha declared_address_match, e a mídia do painel diz o tipo apurado

No módulo address_ocr, o data do check ganha declared_address_match, o CEP e a UF do comprovante contra os endereços que a consulta cadastral de endereços do mesmo fluxo trouxe: cep_match, uf_match, mismatch ou unknown quando falta um dos lados. É informação para você, nunca reprova a verificação e nunca aparece para a pessoa. A rota GET /v1/verifications/{id}/media passa a devolver content_type, o tipo do arquivo apurado pelos bytes na confirmação do upload (null quando não foi apurado). Adição compatível API REST e webhook

​

Novo módulo company_representative, pausado, e o motivo representative_review

O módulo company_representative confere o CPF do representante lido no documento contra o quadro societário que um dos módulos de CNPJ do mesmo fluxo já trouxe, e devolve consta_qsa_administracao, consta_qsa_sem_administracao ou fora_do_qsa em check_details, com indeterminate no resumo quando nada foi conferido. fora_do_qsa nunca reprova sozinho: vai para revisão humana com o motivo novo representative_review. Nenhum desfecho confirma poderes de representação para o ato específico, só a qualificação que o quadro societário publica. O módulo nasce pausado, aparece na tabela de preços com o selo Em breve e o create ou update de flow recusa até a migration de reabertura. Correção API REST e webhook

​

O 402 da criação de sessão passa a conferir o máximo da verificação

POST /v1/verification-sessions em produção passa a conferir o saldo contra o máximo que a verificação pode custar: o preço do flow mais, quando o flow cobra por sócio ou por empresa da cadeia, essas parcelas no teto. Antes conferia só o preço do flow, e a verificação podia debitar além do saldo. A mensagem do 402 insufficient_credit passa a dizer quanto falta. No módulo Proteção de conta, o evento login_failed deixa de ser cobrado, e um 402 de flow com esse módulo nunca aciona a recarga automática.

​

2026-09-25

8 mudanças Adição compatível API REST e webhook

​

Documento de identidade: document.expired e a conferência com a MRZ no cpf_ocr

O data do cpf_ocr ganha document.expired, com três estados: true (vencido), false (vigente) e null (não deu para afirmar). Documento vencido é aceito e nunca reprova. Na CIN e no passaporte, o nome, o nascimento e o número impressos são conferidos com a MRZ: quando não batem, a verificação vai para review com decision_reason identity_document_mrz_review, o motivo do módulo é mrz_visual_mismatch e os campos lidos não vêm. No sandbox, o sufixo 41 simula a divergência e o 45 o documento vencido, que também vale no doc_global. Adição compatível API REST e webhook

​

Teto diário de operações no orçamento, com 429 volume_cap_reached

O orçamento do painel ganha o teto de operações cobradas por dia, para a organização ou para uma chave. Ao alcançá-lo, POST /v1/verification-sessions responde 429 volume_cap_reached com Retry-After até 00:00 UTC. O gasto das sessões criadas por uma chave passa a contar nela também quando a decisão sai depois, e a renovação e o link hospedado herdam a chave. O funil do painel ganha a etapa de verificação exibida ao titular. Adição compatível API REST e webhook

​

Ingestão de transação aceita direction e instrument

O evento de transação aceita direction (in ou out, do ponto de vista do titular; ausente fica registrado como não informado) e instrument, com kind (card, account, wallet ou pix_key) e ref, um valor opaco seu, como o token do seu PSP. Nunca envie o número do cartão: ref com forma de cartão, CPF, CNPJ, e-mail, telefone ou chave Pix é 422 pii_shaped_value, sem eco do valor. Os dois campos estão no openapi.json e nos tipos dos SDKs TypeScript e Python. Adição compatível API REST e webhook

​

Novo no sandbox: o desfecho que muda depois, com o segundo webhook

No sandbox, o CPF de teste terminado em 04 termina em review e, cerca de um minuto depois, é decidido de novo como approved; o terminado em 05, como denied. Chegam dois verification.completed, o segundo com um id de evento novo terminado em _r<número>, para você testar o webhook de atualização sem esperar um caso real. Se alguém decidir pelo painel antes, vale a decisão da pessoa. O -01 termina em review também em flow com face e liveness, e a doc passou a dizer que o CPF de teste vai no campo document do submit pela API, porque o widget submete sem ele. Mudança que quebra API REST e webhook

​

O campo account_event.document_hash deixa de ser aceito

POST /v1/verification-sessions com o bloco account_event passa a recusar o campo document_hash com 400 que nomeia o campo e nunca devolve o valor, com hash ou com documento. O campo nao mudava o resultado do gate de conta e deixa de ser guardado. O código account_event_document_not_hashed sai do contrato. Os SDKs TypeScript e Python deixam de oferecer o campo. Para bloquear um titular no gate de conta, use a lista de bloqueio pelo reference_id. Adição compatível API REST e webhook

​

Bloco de módulo com resposta parcial passa a chegar, marcado com completeness

Quando um módulo de consulta respondeu e parte do dado não veio, o item de check_details traz o bloco data com o que veio, null no que faltou, e o campo completeness com o valor partial. Antes o bloco saía vazio, igual ao de um módulo que nem rodou. Bloco completo não traz o campo. Vale para os módulos de CNPJ, cnpj_ocr, ubo_chain, gov_benefits, doclink, pix_device, state_registration e cndt. E módulo que falhou por dentro passa a sair sem bloco de dado em cpf_ocr, doc_global, fraud_ai e nos níveis de validação de CPF, como o resto do catálogo. Correção API REST e webhook

​

A resposta 201 da criação de sessão documenta os blocos decision e policy

POST /v1/verification-sessions já devolvia, só quando o flow tem o módulo que os produz, o bloco decision (flow com conta: verdict, risk_score de 0 a 100 em faixas de 20, reasons, verification_id e step_up) e o bloco policy (flow com pep_sanctions ou betting_barred: a política efetiva e a origem de cada valor). Os dois passam a constar no openapi.json e nos tipos dos SDKs TypeScript e Python. reasons é uma lista aberta de códigos: trate o que não conhecer como informativo. Correção Painel

​

Editar um flow não mata mais em silêncio o link hospedado já enviado

A edição de flow que tornaria impossível abrir um link de verificação ainda válido (por exemplo, trocar os módulos pelo gate transacional) responde 409 flow_has_active_links, com a contagem dos links. O editor oferece revogar os links ativos e salvar em seguida. Link consumido, revogado ou vencido não conta, e a edição que não afeta o resgate segue igual.

​

2026-09-24

4 mudanças Adição compatível Painel

​

Lista de permissão: menos atrito na prova de vida para o titular que a conta já aprovou

No painel, o proprietário, ou um administrador a quem ele deu a capacidade, concede permissão a partir de uma verificação aprovada, para a conta inteira ou só para um flow, com validade obrigatória de até 180 dias e segundo fator em toda concessão. O efeito é um só: na prova de vida adaptativa, a sessão daquele titular recebe menos atrito. A permissão nunca dispensa identidade: rosto, prova de vida, documento, sanções e lista de bloqueio decidem como sempre, e a lista de bloqueio vence. Nenhuma rota de API cria ou lê a lista: uma chave vazada não consegue permitir ninguém. Na mesma entrega, o painel ganhou a simulação de política sobre o próprio histórico, em Motor, que mostra o que teria mudado nas verificações já decididas antes de qualquer ajuste no flow. Adição compatível API REST e webhook

​

PLD/FT: módulos pld_monitor e pld_risk, campos cash e counterparty_country, bloco pld_profile

Dois módulos contratáveis de 5 centavos: pld_monitor, que seleciona operações e situações pela relação da norma do seu setor, cobrado por pessoa monitorada no mês, e pld_risk, que classifica o risco do cliente na verificação, cobrado só quando classifica. O evento de transação aceita cash (booleano, padrão false) e counterparty_country (ISO 3166-1 alfa-2 de lista fechada), e a criação de sessão e a ingestão aceitam o bloco opcional pld_profile. Dois códigos 422 entram no contrato: counterparty_country_invalid e pld_profile_invalid, com o índice ou o campo na mensagem e nunca o valor. O pld_monitor é exclusivo no flow e não abre sessão de widget. Os SDKs TypeScript e Python conhecem os campos, o bloco e os códigos. Adição compatível API REST e webhook

​

Evento pld.alert.created no webhook do flow com pld_monitor

Quando o monitoramento de PLD/FT seleciona uma operação ou situação, o webhook do flow recebe pld.alert.created, com a mesma assinatura, os mesmos headers e as mesmas retentativas dos eventos de verificação. O corpo é mínimo e sigiloso: o id do alerta, a sua reference_id, a severidade, o tipo, os itens da norma, o fundamento, a data da seleção, os vencimentos e o caminho do alerta no painel. Nenhuma evidência, valor ou operação. Não é evento de verificação: o envelope verification.* não muda, e GET /v1/webhook-events passa a listar pld_alert_created quando a entrega não chegou. Os SDKs ganharam o tipo do aviso e o isPldAlertEvent. Correção API REST e webhook

​

Link hospedado recusado para flow com assinatura ou custódia da autorização

POST /v1/verification-links responde 422 assinatura_document_required quando o flow tem o módulo assinatura, e 422 consultation_authorization_required quando tem o módulo authorization_custody. Os dois exigem, na criação da sessão, um bloco que o link não carrega (o hash do documento, ou o hash, a versão e o escopo do texto da autorização): a emissão era aceita e todo titular que abria o link recebia erro. A sessão desses flows nasce por POST /v1/verification-sessions, com o bloco. Os códigos já existiam na criação de sessão.

​

2026-09-23

5 mudanças Adição compatível API REST e webhook

​

Origem da jornada: origin_tag na criação de sessão, ecoado no webhook

POST /v1/verification-sessions aceita o campo opcional origin_tag, um rótulo seu para a origem da jornada (a campanha, o canal, a tela de onde a pessoa veio), de 1 a 64 caracteres entre letras, dígitos, ponto, sublinhado, dois-pontos e hífen. Ele volta exato no 201 da criação e no data.origin_tag do webhook da verificação, e a sessão renovada pelo widget herda o valor. Sem o campo, nenhuma resposta muda. Junto do bloco de transação ele é recusado com 422 origin_tag_not_supported. Adição compatível API REST e webhook

​

Bloco consultation_authorization na criação de sessão e requires_any_of em capabilities

POST /v1/verification-sessions aceita o bloco consultation_authorization (text_sha256, text_version e scope), obrigatório quando o flow tem o módulo authorization_custody (422 consultation_authorization_required), recusado quando não tem (422 consultation_authorization_not_supported), e fechado: chave desconhecida dentro dele é 400 unknown_consultation_authorization_key. GET /v1/capabilities passa a trazer requires_any_of no módulo que exige ao menos um de um grupo de alternativas no mesmo flow, como a inscrição estadual, que precisa de um dos níveis de consulta de CNPJ. Os SDKs TypeScript e Python conhecem os códigos e o campo. O módulo authorization_custody ainda não está à venda. Adição compatível API REST e webhook

​

Orçamento diário de gasto configurável no painel, com 429 spend_cap_reached na criação de sessão

POST /v1/verification-sessions passa a declarar 429 spend_cap_reached, com Retry-After em segundos até 00:00 UTC, quando o orçamento diário que a conta configurou no painel (Operação, Orçamento) para a organização ou para a chave acabou no dia. O teto nasce desligado: quem não configurou nada nunca recebe o código. Diminuir vale na hora; aumentar ou desligar vale na virada do dia (UTC). O painel ganhou também o funil de conversão por etapa e por flow, e o registro de requisições da API por 30 dias, só com metadado: identificador, credencial, rota padrão, status e duração, nunca o corpo. Os SDKs TypeScript e Python conhecem o código novo. Adição compatível API REST e webhook

​

pep_sanctions devolve pending quando a lista não foi consultada

Além de dataset_stale, o módulo passa a responder pending com no_coverage (nenhuma lista do módulo disponível) e com critical_source_disabled (uma lista que a resposta não pode dispensar está fora do ar). Os dois vão para review e não são cobrados, como o dataset_stale já ia. Em cnpj_partners os mesmos motivos aparecem no bloco partner_screening com status unavailable. dataset_versions ganhou record_count, e uma lista não consultada aparece em aggregates.by_list com null em vez de sumir do objeto. Correção API REST e webhook

​

Flow com o gate transacional é exclusivo: a composição mista é recusada na criação

POST /v1/flows e PATCH /v1/flows/{id} respondem 422 sync_gate_module_exclusive quando o módulo transacao aparece junto de qualquer outro módulo. A composição mista era aceita e não rodava por caminho nenhum: a chamada com o bloco transaction responde na hora e não abre jornada de captura, então os módulos de documento e de biometria daquele flow ficavam parados sem erro. Mantenha o seu KYC no flow que você já tem e crie um flow separado só com o gate; os dois se encontram pelo mesmo reference_id.

​

2026-09-22

1 mudança Adição compatível API REST e webhook

​

Ingestão de transações: dois códigos de erro entram no contrato e o flow com gate exige o bloco

POST /v1/verification-sessions passa a declarar 422 settlement_status_invalid (liquidação ou reversão enviada com status pending) e 429 daily_ingest_cap_reached (teto diário de eventos por organização, sem Retry-After: o balde é o dia). Num flow que contenha o gate transacional, a chamada sem o bloco transaction responde 422 transaction_required, na criação de sessão e na emissão de link hospedado. Nenhum campo mudou de forma; os SDKs conhecem os dois códigos novos.

​

2026-09-19

3 mudanças Correção API REST e webhook

​

Endereço de webhook protegido nas respostas de leitura

Em GET /v1/webhook-events e no detalhe de uma entrega, target_url traz o host do destino. O endereço completo, que pode carregar credencial do seu receptor, aparece só para dono e administrador, na tela de endpoints. O campo e o tipo continuam os mesmos. Correção Painel

​

Webhooks e Flows mostram o host do destino para quem não administra endpoints

Perfis de desenvolvimento e de leitura continuam escolhendo o webhook de um flow normalmente, agora pelo host. Dono e administrador seguem vendo o endereço completo. Adição compatível API REST e webhook

​

Header x-idsaas-delivery-id em toda entrega de webhook

Cada POST leva o identificador da entrega. Ele se repete em todas as tentativas e no replay, então você correlaciona as tentativas sem abrir o corpo.

​

2026-09-18

4 mudanças Adição compatível Painel

​

Sessões: bloquear e desbloquear um titular pela sua referência

Em Sessões, quem é dono ou administrador bloqueia um titular pelo reference_id, na conta inteira ou em um flow, e desfaz o bloqueio na mesma tela. Serve para quem abandonou a verificação antes de existir documento. Correção API REST e webhook

​

Gate transacao: o veredito deny considera o reference_id da transação

No módulo transacao, quando o reference_id enviado está na sua lista de bloqueio o veredito é deny, com blocklist_hit em reasons. Envie sempre o reference_id do titular junto da transação: é por ele que a sua lista é consultada. Adição compatível API REST e webhook

​

Lista de bloqueio: o reference_id passa a barrar a verificação

O titular que você bloqueou pelo reference_id termina a próxima verificação em blocked, sem cobrança, e o webhook verification.blocked chega com reason igual a reference_blocklisted. É um valor a mais em reason, que a política desta página já obriga a tolerar. Correção API REST e webhook

​

Flow exclusivo do monitoramento transacional deixa de aceitar sessão e link

Criar sessão ou link num flow que só recebe alertas do monitoramento transacional passa a responder 422 session_not_supported. Antes a sessão era aceita e produzia um resultado em revisão sem análise nenhuma. Nada muda para quem envia eventos com o bloco transaction, nem para os seus flows de verificação.

​

2026-09-17

4 mudanças Correção API REST e webhook

​

Gate transacao: só movimento do titular que não falhou recebe veredito e cobrança

No módulo transacao, a verificação e a cobrança passam a sair só para o movimento que o próprio titular iniciou e que não falhou: deposit, withdraw, transfer, payment e bet, com status confirmed ou pending. Os eventos settlement e reversal (que são o ciclo de vida de um pagamento já julgado), bet_profit e bet_loss (que são o resultado apurado pela casa), qualquer evento com status failed e o backfill que chega fora da janela normal continuam sendo ingeridos, entram na trilha, na retenção e no monitoramento, e deixam de gerar verificação, webhook de verificação e débito. Antes cada um deles produzia uma verificação cobrada, o que na prática cobrava duas vezes pelo mesmo pagamento. Se a sua integração contava uma verificação por evento enviado, passe a contar por evento avaliável. Correção API REST e webhook

​

Gate transacao: mandar só device.ip deixa de zerar a penalidade de dispositivo

Quem já tinha mandado device.fingerprint antes para o mesmo titular e para de mandar passa a receber device_data_dropped em reasons, mesmo quando o device.ip continua indo na chamada. Antes um device.ip sozinho contava como dispositivo presente e zerava a penalidade inteira. Nada muda para quem sempre mandou os dois campos, e nada muda na forma do corpo: é uma razão a mais em reasons, que a política desta mesma página já obriga a tolerar. Mudança que quebra Widget

​

Marca do widget: os textos voltam vazios quando a conta não escreveu os seus

A resposta de marca lida com o segredo da sessão passou a trazer título, subtítulo e texto do botão APENAS quando a conta escreveu os seus. Conta que nunca customizou recebe esses três campos nulos, e o widget usa o texto do próprio catálogo, no idioma da sessão. Cores, raio e fonte não mudaram. Saiu também o idioma padrão da conta, que é configuração do painel e não tem uso no widget. Quem monta a própria tela a partir dessa resposta deve tratar os três textos como opcionais. Mudança que quebra Painel

​

Consulta avulsa: a resposta passou a ter um conjunto fechado de campos

O corpo de POST /v1/lookup-queries e os itens de GET /v1/lookup-queries passaram a trazer apenas o que descreve a SUA consulta: identificador, ambiente, módulo, tipo de documento, finalidade, situação, se a fonte encontrou o documento, o preço, se foi cobrada, quem pediu e quando foi pedida. Saíram três campos que descreviam o funcionamento interno da plataforma e não a sua consulta: o estado do cache, a impressão digital do documento e o carimbo de conclusão. Quem lia algum deles passa a ler ausente. Para saber se uma consulta custou, use price_cents e billed, que continuam no mesmo lugar e respondem exatamente isso. Nenhum campo mudou de nome, de tipo ou de significado, e nada foi acrescentado.

​

2026-09-11

8 mudanças Adição compatível API REST e webhook

​

Módulo doclink contratável: Reuso de Documento

O módulo doclink passou a ser contratável: em GET /v1/capabilities ele sai com status available em vez de coming_soon, e POST /v1/flows passa a aceitá-lo. Ele dispensa a foto do documento de quem você já aprovou antes: o titular faz a prova de vida e a selfie, o módulo compara essa selfie com a da verificação anterior da mesma conta na SUA base e reaproveita os dados que já tinham sido lidos do documento naquela vez. No flow ele SUBSTITUI a Verificação de Identidade e o Face Match, e exige o Liveness, que é o que impede reusar uma identidade com a foto de uma foto. Quem nunca foi verificado por você não tem o que reusar, e a verificação vai para revisão em vez de ser recusada. Nada muda no formato de check_details: o bloco do módulo é o mesmo que já estava documentado durante a pausa. O preço é de 25 centavos por verificação. Adição compatível API REST e webhook

​

Módulo transaction_monitor contratável: monitoramento transacional cobrado por alerta

O módulo transaction_monitor passou a ser contratável: em GET /v1/capabilities ele sai com status available em vez de coming_soon, e POST /v1/flows passa a aceitá-lo. Ele varre, sem ninguém esperando, as transações que você já mandou pela rota de ingestão, e quando um padrão fecha o alerta chega no mesmo webhook assinado de sempre, com a janela e a evidência em número. O alerta nunca reprova ninguém: o pior desfecho é revisão humana. A cobrança é por ALERTA EMITIDO, 30 centavos: a varredura é grátis e alerta suprimido por repetição não custa nada. Ele é exclusivo no flow, a mesma regra do monitoramento de sessão: um flow que o contenha não aceita nenhum outro módulo, e pedir isso responde 422 system_module_exclusive. Nada muda no formato de check_details. Adição compatível API REST e webhook

​

Módulo monitoring_aml contratável: monitoramento contínuo por titular e por mês

O Monitoramento Contínuo passou a ser contratável, a 10 centavos por titular monitorado por mês. Atenção ao que ele NÃO é, porque isso decide a sua integração: ele não é item do array modules de um flow, e pedir isso continua sendo recusado. Quem liga o monitoramento é o campo monitoring_enabled do flow, em POST /v1/flows e em PATCH /v1/flows/{id}, ou o bloco monitoring da criação da sessão, e esses campos deixaram de responder 422 monitoring_unavailable: agora são aceitos. Depois da aprovação o titular fica sob vigilância contínua nas mesmas listas oficiais do PEP e Listas Restritivas, sem nenhuma captura nova, e quando ele passa a constar de uma lista em que não constava no onboarding você recebe o webhook com a evidência minimizada e uma verificação de acompanhamento em revisão. O alerta nunca decide sozinho: quem revisa é você. Adição compatível API REST e webhook

​

Módulo transacao contratável: gate transacional, e o lote recusado no flow que o contém

O Gate Transacional passou a ser contratável, a 12 centavos por transação avaliada: em GET /v1/capabilities ele sai com status available em vez de coming_soon, POST /v1/flows passa a aceitá-lo e a ingestão de transações deixou de responder 422 transaction_not_supported em flow que o contenha. A consequência que você precisa ler ANTES de integrar: num flow que contenha o gate, enviar transactions[], que é o lote, passa a responder 422 batch_not_supported_for_gate, e só a forma unitária transaction é aceita. A razão é de produto e não de implementação: um gate síncrono decide UM pagamento, e um lote não teria veredito. Isso é adição compatível e não mudança que quebra, e o argumento é verificável: até esta data nenhum flow podia conter o módulo, porque a criação de flow o recusava, então não existe integração afetada. A regra nasce junto com a possibilidade. Adição compatível API REST e webhook

​

PGFN Dívida Ativa virou consulta de empresa, e o data do módulo mudou de forma

O módulo credit_pgfn passou a ser contratável e trocou de produto dentro do mesmo nome. Ele deixou de consultar o CPF e passou a consultar o CNPJ, então a dependência no flow deixou de ser Verificação de Identidade, Face Match e Liveness e passou a ser apenas o OCR do documento de empresa: empresa não tem rosto, e cobrar biometria aqui seria cobrar por uma prova que não prova nada. A fonte deixou de ser certidão comprada de fornecedor e passou a ser o dado aberto oficial da Dívida Ativa da União, publicado e atualizado mensalmente pela PGFN e servido da nossa base. E o campo data do módulo MUDOU DE FORMA, dito aqui em voz alta: antes era o repasse do dossiê do fornecedor, com a lista de inscrições e o número de cada uma; agora traz principal, corresponsavel e solidario separados, mais competencia, atualizado_em e cobertura. Os três papéis vêm separados porque corresponsável costuma ser dívida de outra empresa pela qual a consultada responde, e somar tudo acusaria de devedor quem não é. Não há número de inscrição: a base agrega por documento e por papel. Quando ela está vencida ou incompleta o módulo responde pendente com o motivo e não é cobrado, em vez de dizer que nada consta sobre uma cópia velha. Mudar a forma de um campo é adição compatível SÓ porque este módulo nunca esteve à venda: ele saiu de coming_soon direto para available, e não existe integração lendo o formato antigo. Adição compatível API REST e webhook

​

Preço do módulo credit_pgfn de R$17,90 para R$ 0,45

A consulta de Dívida Ativa da União passou a custar 45 centavos, contra os 1790 centavos que o catálogo publicava desde que o módulo nasceu. A queda de 97,5% não é promoção e não tem prazo: ela é a consequência de a fonte ter deixado de ser uma certidão comprada por consulta e passado a ser a nossa base do dado aberto oficial da PGFN, sem fornecedor no caminho. O valor novo já viaja em GET /v1/pricing-catalog/public, que continua sendo a única fonte de preço que a nossa vitrine e a sua integração devem ler. Adição compatível API REST e webhook

​

reason_code separa a evidência do desfecho, e agrupa as razões

O bloco reason_code do corpo do webhook ganhou dois campos. O primeiro é reasons, uma lista em que cada razão separa o que foi visto do que isso causou: code é a evidência, no mesmo vocabulário que decision_reason já usava, e outcome_effect diz se ela bloqueou, mandou para revisão ou apenas ficou registrada. Cada razão também traz o módulo de origem, o grupo a que ela pertence e dois textos prontos em português, display_pt para a sua tela e action_pt com o que fazer a seguir. O segundo campo é aspects, o índice desses códigos por cinco grupos, documento, biometria, validação de dado, sinais de fraude e canal, sempre com as cinco chaves, mesmo vazias. A primeira razão da lista é sempre a que puxou a decisão e o código dela é idêntico ao decision_reason, então nada de novo passa a ser dito: o que muda é a forma. Nenhum campo saiu e nenhum mudou de valor, os textos display_pt e action_pt são para quem integra e não para o titular, que continua recebendo apenas subject_message, e schema_version segue valendo 1, como a política desta mesma página prevê para adição de campo. Adição compatível API REST e webhook

​

Verificação de idade voltou a ser vendável

O módulo idade voltou ao catálogo como contratável: em GET /v1/capabilities ele sai com status available em vez de coming_soon, e POST /v1/flows passa a aceitá-lo. A pausa, anunciada em 21 de agosto, era por licença do modelo que estima a idade, não por defeito: o peso anterior tinha origem de dados restrita a pesquisa e foi retirado do produto. O que roda agora tem cadeia de licença aberta e verificável, e a atribuição exigida por ela está publicada na página de segurança. Nada muda no formato da resposta nem nos campos de check_details: o contrato do módulo é o mesmo que já estava documentado durante a pausa. O preço é de 50 centavos por verificação.

​

2026-08-29

1 mudança Adição compatível API REST e webhook

​

betting_barred: a base entrou no ar, e a cobertura anunciada encolheu para o que ela é

O módulo deixou de sair pendente por falta de base: a lista de agentes públicos do setor de apostas do Portal da Transparência está carregada e o módulo passa a devolver veredito, com coverage e dataset_versions como prova de diligência. Na mesma entrega a cobertura anunciada encolheu, e é a parte que importa para quem já integrou: atleta e árbitro SAÍRAM. A CBF não publica base para conferência automática, e as duas fontes dela passam a viajar em dataset_versions como disabled, ou seja, declaradamente não consultadas, em vez de aparecerem como cobertura. Preferimos dizer o que não cobrimos a listar uma fonte que não conseguimos conferir. Nada muda no formato do payload nem no preço; muda o que a resposta afirma.

​

2026-08-28

3 mudanças Adição compatível API REST e webhook

​

Quatro módulos novos: forense de documento, rede de fraude, documento de viagem e cadeia societária

Quatro módulos novos no catálogo, cada um com bloco próprio em check_details. Forense de documento pericia o ARQUIVO que a verificação de identidade já capturou (ferramenta que o gerou, datas, revisões de PDF, recaptura de tela, recorte e colagem), sem pedir foto nova. Detecção de rede de fraude mostra se quem está se verificando está ligado a outras contas SUAS, por aparelho, rede, e-mail, telefone, rosto ou pela conta que você informa, e a rede é sempre a sua. Documento de viagem lê a zona de leitura mecânica (MRZ) de passaportes e carteiras estrangeiras no padrão ICAO 9303, com todos os dígitos verificadores, e ocupa o lugar da verificação de identidade no mesmo flow. Cadeia societária sobe o quadro nível a nível quando um sócio é outra empresa, até as pessoas naturais, com o percentual acumulado. Nenhum dos quatro reprova sozinho: um achado leva a verificação para revisão humana com a evidência. A cadeia societária é cobrada por empresa efetivamente subida, e o teto por verificação é definido por você no flow. Adição compatível API REST e webhook

​

policy.ubo_max_paid_nodes na criação de sessão, e dois códigos de erro novos

A política por sessão ganhou a chave ubo_max_paid_nodes, o teto de empresas da cadeia societária que aquela verificação pode subir. Ela só APERTA o teto do flow: pedir mais que ele responde 422 policy_ubo_cap_above_flow, nunca um corte silencioso, porque gasto só sobe por decisão registrada e auditada no flow. Na mesma passada entrou no spec o 422 policy_module_not_in_flow, que já existia e não estava publicado: política para um módulo que o flow não tem é recusada com nome, nunca aceita e ignorada. As duas regras valem igual na criação de sessão e na emissão de link hospedado. Adição compatível API REST e webhook

​

Link de verificação hospedado publicado no contrato

POST /v1/verification-links passa a constar do spec OpenAPI e da documentação. A rota já estava no ar e é a quarta da superfície da chave secreta: para quem não vai montar o widget, nós hospedamos a página e você entrega a url ao titular. O link vive horas, a sessão só nasce no resgate e vive 15 minutos, o token do link volta em claro uma vez só e não é reexibido, e emitir link não cobra nada: quem cobra é a verificação que nascer do resgate. Nada mudou no comportamento; o que mudou é que o contrato público parou de omitir a rota.

​

2026-08-27

1 mudança Adição compatível API REST e webhook

​

Módulo adverse_media: mídia adversa (negative news)

Módulo novo no catálogo (40 centavos), com bloco próprio em check_details. Confere o nome lido do documento contra um corpus aberto de notícias mantido por nós. Todo casamento é por nome e a resposta sempre declara o grau de confiança (name_match forte ou possível homônimo) e a similaridade. Um hit forte nunca reprova sozinho: leva a verificação para revisão humana com a evidência (fonte, data e link). Exige Verificação de Identidade, Face Match e Liveness no mesmo flow, e desliga a renovação de sessão pelo widget. Enquanto o corpus não estiver carregado, toda checagem sai pendente (indeterminado), vai a review e não é cobrada, nunca um falso nada consta.

​

2026-08-25

1 mudança Adição compatível API REST e webhook

​

Módulo betting_barred: vedação de apostas (Lei 14.790/2023)

Módulo novo no catálogo (45 centavos), com bloco próprio em check_details e a chave opcional policy.allow_betting_ban na criação da sessão com sk_. Confere o CPF e o nome do documento contra as listas públicas de impedidos (CBF BID, arbitragem, servidores do setor) e devolve coverage e dataset_versions como prova de diligência. Exige Verificação de Identidade, Face Match e Liveness no mesmo flow, e desliga a renovação de sessão pelo widget. Nunca reprova sozinho: um sinal leva a verificação para review. Enquanto o feed das fontes não estiver carregado, toda checagem sai pendente, vai a review e não é cobrada.

​

2026-08-22

1 mudança Adição compatível API REST e webhook

​

schema_version no corpo do webhook, e a garantia de entrega publicada

O envelope de todo evento passa a carregar schema_version, a versão da FORMA do corpo. Hoje ela vale 1 e não sobe por adição compatível: campo novo, módulo novo em check_details e valor novo em enum de saída continuam com schema_version 1. Ela só muda se um campo mudar de tipo ou de significado, e isso já exigiria uma versão nova de caminho. É campo NOVO na resposta, ou seja, adição compatível pela regra desta mesma política. Junto vai para a documentação, por escrito, a garantia de entrega que já praticávamos: pelo menos uma vez, com repetição possível, e o id do evento como chave de deduplicação do seu lado.

​

2026-08-21

8 mudanças Adição compatível API REST e webhook

​

Módulo pep_sanctions: PEP e listas restritivas

Módulo novo no catálogo (40 centavos), com bloco próprio em check_details e a chave opcional policy.allow_pep na criação da sessão com sk_. Exige Verificação de Identidade, Face Match e Liveness no mesmo flow. Nunca reprova sozinho: um sinal leva a verificação para review. Chave de política desconhecida é 400, que é a validação nova valendo só para um parâmetro novo. Adição compatível API REST e webhook

​

Módulo email_otp e as duas rotas de OTP da sessão

Validação de e-mail por código (10 centavos). Entram POST /v1/verification-sessions/{id}/otp e POST /v1/verification-sessions/{id}/otp/verify, autenticadas pela própria sessão do widget, e o bloco email_otp em check_details. Nenhuma rota nova de sk_. Adição compatível API REST e webhook

​

Módulos telefone e sms_otp

Validação de telefone contra a base oficial de numeração, sem envio (15 centavos), e validação por SMS (115 centavos). O sms_otp nasce INATIVO no catálogo, à espera do contrato de SMS: até o flip por migration nova ele não aparece no catálogo público nem entra em flow. Correção API REST e webhook

​

Cobrança do sms_otp unificada no fecho da verificação

O sms_otp debitava no despacho da mensagem, fora do caminho por onde o resto do catálogo cobra. Passou a cobrar no fecho, como todos os outros módulos. Nenhum campo de resposta mudou: o que muda é o momento do débito no seu saldo. Adição compatível Widget

​

Widget em português, inglês e espanhol

O texto que a pessoa vê passa a existir em pt-BR, en-US e es-ES. O idioma sai da dica do host (mount({ locale: ‘en’ }) ou data-locale), senão do navegador, senão pt-BR. O widget já tolera um campo de idioma vindo do servidor, que ainda NÃO existe na API: quando ele nascer, o bundle antigo continua funcionando, e idioma desconhecido mantém a língua que já estava. Adição compatível Painel

​

Recuperação de senha do painel

Telas /esqueci-senha e /redefinir-senha, com link por e-mail de uso único e validade curta. A resposta é sempre a mesma, exista a conta ou não, para a tela não virar consulta de quem tem cadastro. Nada muda na API REST nem no widget. Adição compatível Site público

​

Preços e comparativos públicos

As páginas /precos e /comparar passam a existir, servidas do catálogo público de preços, não de uma tabela escrita à mão. Módulo que não está ativo no catálogo aparece como Em breve, nunca com preço de venda. Depreciação API REST e webhook

​

Venda do módulo idade pausada

O módulo idade saiu do catálogo público e deixou de ser vendável, à espera de decisão do dono sobre religar a venda. A saída foi no mesmo dia do aviso, sem os 90 dias que a política de versão passa a exigir daqui em diante, porque não havia nenhuma integração ativa para avisar. A partir desta publicação, saída de módulo do catálogo cumpre o prazo. Sai do ar em 2026-08-21.

​

2026-08-09

1 mudança Mudança que quebra API REST e webhook

​

Módulo ocr renomeado para cpf_ocr

A leitura de documento de pessoa passou a se chamar cpf_ocr, por simetria com o cnpj_ocr do KYB. Quem lia check_details procurando module igual a ocr deixou de encontrar o bloco. O histórico foi renomeado junto, então verificações antigas também aparecem como cpf_ocr.

​

2026-08-06

1 mudança Adição compatível API REST e webhook

​

Módulos idade e unique_face

Verificação de idade e detecção de múltiplas contas, ambos rodando sobre a selfie já capturada: zero passo novo no widget. Entram como valores novos no catálogo de módulos e como blocos novos em check_details.

​

2026-08-05

1 mudança Mudança que quebra API REST e webhook

​

Módulo socios extinto, cnpj vira cnpj_partners

O quadro societário já vinha na mesma resposta do módulo de CNPJ, então o módulo socios era redundante e foi removido; o módulo cnpj passou a se chamar cnpj_partners. Flow que pedia socios perdeu o módulo, e o preço do flow foi recalculado pela soma dos módulos restantes.

​

2026-08-02

1 mudança Mudança que quebra API REST e webhook

​

Módulos de validação de CPF renomeados

cpf virou cpf_contacts, cpf_k virou cpf_addresses, cpf_e virou cpf_status e cpf_i virou cpf_companies. Os nomes antigos eram códigos de pacote do nosso fornecedor de dados, sem significado para quem integra. O histórico de verificações foi renomeado junto.

​

2026-07-28

1 mudança Mudança que quebra API REST e webhook

​

Combos de preço removidos: preço do flow é a soma dos módulos

As tabelas de combo saíram e o preço de um flow passou a ser sempre a soma dos preços unitários dos módulos escolhidos. Além de simplificar, isso corrigiu preço gravado errado: quando a lista de módulos casava inteira com uma chave de combo, o combo vencia a soma e cobrava mais caro. Os preços dos flows existentes foram recalculados.

​

2026-07-27

1 mudança Adição compatível API REST e webhook

​

Módulo cnpj_ocr: leitura do documento da empresa

OCR do comprovante de CNPJ, separado do OCR de documento de pessoa. KYC e KYB viram módulos independentes e podem conviver no mesmo flow.

​

2026-07-01

1 mudança Adição compatível API REST e webhook

​

Status review nas verificações

O enum de status ganhou review, para separar revisão humana de pending, que significa em processamento. Este é o exemplo canônico de adição compatível: valor novo em enum de saída. Integração que tratava status desconhecido como erro precisou tolerar o valor novo.

​

2026-06-29

1 mudança Mudança que quebra API REST e webhook

​

Widget autentica por client_secret da sessão, fim da chave publicável

O widget passou a autenticar pelo segredo escopado a UMA sessão, em vez de uma chave pública de conta. A chave publicável pk_ saiu do produto: hoje ela não parseia e devolve 401. Trocar o segredo global pelo segredo de sessão foi a mudança que tirou credencial de conta do navegador.

​

2026-06-24

1 mudança Adição compatível API REST e webhook

​

Publicação da API sob /v1

Primeira versão do contrato HTTP, montada no caminho /v1. É o marco zero deste changelog: tudo acima aconteceu dentro desta mesma versão de caminho. Não vê aqui uma mudança que você percebeu na integração? Isso é um defeito nosso, e a gente quer saber: fale com o suporte pelo painel. Changelog incompleto vale menos que changelog nenhum.