> ## Documentation Index > Fetch the complete documentation index at: https://docs.unifokal.com/llms.txt > Use this file to discover all available pages before exploring further. # Changelog da API > Tudo o que já mudou na API UNIFOKAL, em ordem cronológica, classificado em mudança que quebra, adição compatível, correção e depreciação. Cada item cita a prova da data. 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](https://docs.unifokal.com/versionamento.md). Ú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](https://unifokal.com/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`](https://unifokal.com/docs/changelog.json), para você observar mudança sem raspar esta página. Mudança que quebra 29 Adição compatível 101 Correção 32 Depreciação 3 > [!NOTE] > > **Como datamos.** A data de cada item vem da migration que aplicou a mudança ou do documento interno que registra a entrega, e o item mostra qual das duas. Onde o número da migration usa uma faixa reservada de numeração, que não é data de nada, a data vem do documento. Nenhuma data é estimada: item sem prova não entra nesta lista. ## 2026-10-24 13 mudanças Adição compatível API REST e webhook ### O endereço da documentação passa a ser docs.unifokal.com O docs\_url de GET /v1/capabilities e o contato e o externalDocs da spec OpenAPI passam a apontar para o site da documentação, docs.unifokal.com. O endereço antigo, /docs, continua respondendo com redirecionamento permanente para lá. Correção API REST e webhook ### passive\_liveness: imagem única e quadros de outro rosto vão à revisão humana Com o passive\_liveness, a imagem única (evidence\_level single\_image) não aprova mais no automático: a verificação vai à revisão humana com passive\_liveness\_missing e o status do módulo sai review. A sequence passa a exigir que os quadros mostrem o mesmo rosto da selfie; quadros de outro rosto contam como single\_image e a verificação vai à revisão com passive\_liveness\_unverified. O rosto de referência do match é só o do documento lido no flow por cpf\_ocr ou doc\_global. No gate de conta, reward\_claim e withdrawal passam a considerar a detecção mais grave do histórico de múltiplas contas do titular, e não a última. Duas mudanças no bloco data do passive\_liveness: o status pode vir null depois de 180 dias, quando o laudo de que ele dependia sai com a redação de evidência, e o evidence\_level single\_image passa a cobrir também a sequência cujos quadros não são o rosto da selfie. Por isso o schema\_version do webhook sobe para 4. Adição compatível API REST e webhook ### metadata na criação de sessão e de link A criação de sessão e a de link aceitam metadata, até 20 pares de texto seus (chave de até 40 caracteres, valor de até 500). Os valores voltam exatos no 201, no data.metadata do webhook da verificação e no dossiê do painel, e a sessão aberta pelo link herda os mesmos pares. O metadata nunca decide nada. Valor com forma de dado pessoal é recusado com 422 pii\_shaped\_value, e junto do bloco de transação o campo é recusado com 422 metadata\_not\_supported. Adição compatível Painel ### Simular política: as verificações que dependem de uma verificação alterada ficam fora da conta A simulação de política que não é a da lista passa a andar na ordem em que as verificações da conta aconteceram. Quando uma verificação alterada pode mudar o resultado de outra, pela mesma referência, pelo mesmo aparelho, pela mesma rede ou pelo mesmo documento, a outra sai da conta em row\_not\_evaluable. A resposta de GET /v1/decision-backtests/:id ganha status\_feedback.refused, o total delas, e bounds, cada direção como o intervalo entre a contagem e a contagem mais as que ficaram fora da conta. A tela Motor mostra o total, as premissas e o intervalo de cada direção. Mudança que quebra API REST e webhook ### Monitoramento contínuo: os avisos de ciclo de vida ganham código próprio em reason\_code Os seis avisos de ciclo de vida do monitoramento contínuo (pausa por saldo, pausa por lista indisponível, retomada, fim da janela, fim por apagamento e fim pela sua conta) passam a trazer em reason\_code.code o próprio aviso, o mesmo valor de decision\_reason, e não mais technical\_error. Trate esses códigos como ciclo de vida, não como erro. Mudança que quebra API REST e webhook ### Formato novo da chave secreta: unifokal\_live\_ e unifokal\_test\_ A chave secreta passa a começar com unifokal\_live\_ (produção) ou unifokal\_test\_ (sandbox), seguida de 64 hexadecimais e de um código de conferência de 8 hexadecimais. Uma chave no formato anterior responde 401 invalid\_api\_key e precisa ser trocada no painel. O segredo da base do cliente passa a começar com unifokal\_src\_. O segredo de assinatura do webhook continua o que você cadastra. Depreciação API REST e webhook ### Evento de conta: risk\_level entra e risk\_score fica obsoleto A resposta da criação de sessão com o módulo conta ganha decision.risk\_level, a faixa do risco em ordem crescente: low, medium, high. O decision.risk\_score continua saindo como hoje e fica obsoleto: ele sai na versão 2 da API. Leia a faixa no lugar do número. **Sai do ar em 2027-10-24.** Adição compatível API REST e webhook ### Teto de valor por transação no flow: max\_amount\_cents e amount\_above\_flow\_ceiling O flow ganha o campo opcional max\_amount\_cents, o teto de valor por transação em centavos. A ingestão aplica o menor entre ele e o teto geral da plataforma, e o evento acima do teto do flow é recusado com 422 amount\_above\_flow\_ceiling, sem gravar nada do lote. Flow sem o campo segue só com o teto geral. Mudança que quebra API REST e webhook ### Webhook cifrado: o header x-idsaas-event chega como verification.event Com a cifra da carga ligada no destino, o header x-idsaas-event passa a chegar genérico, verification.event, e o tipo do evento fica só dentro do corpo cifrado. O id do evento também chega opaco, evt\_ seguido de 32 caracteres hexadecimais, no x-idsaas-event-id, no event\_id do envelope e no id do corpo aberto, o mesmo em toda tentativa e no reenvio. Quem vê o tráfego não aprende qual evento passou nem de qual recurso. Destino sem cifra continua recebendo verification.\ no header e o id de sempre. Adição compatível API REST e webhook ### Verificação recusada por consulta cadastral sai sem o dado cadastral Quando a recusa vem da consulta cadastral, como a do óbito registrado na fonte, a verificação chega com o desfecho e o código de motivo, sem o bloco data dos módulos cadastrais, sem o resultado campo a campo da Coerência Cadastral e sem a empresa. O nome e o nascimento do cpf\_ocr passam a ser os lidos do documento. Nos demais desfechos nada muda: o dado cadastral continua saindo só com a identidade comprovada. Mudança que quebra Painel ### Marca do widget: subtítulo e texto do botão saem Os campos subtitle e button\_text deixam a customização e a API de marca, porque o widget nunca os mostrou. O título, as cores, o raio, a fonte e o idioma continuam. Enviar um dos dois campos passa a responder 400. 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](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 \\_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](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\, 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.