Toda mudança do contrato público, da mais recente para a mais antiga, classificada em quatro classes e nada além delas. O que define cada classe está na política de versão. Última mudança publicada: 2026-08-29.
A API ainda não está em produção. Enquanto o primeiro ambiente produtivo não sobe, a data de cada item é o dia em que a mudança passou a fazer parte do contrato, e não o dia em que entrou no ar. A página de status mostra o mesmo fato pelo outro lado: não há medição sendo publicada ainda.
Existe também o mesmo conteúdo legível por máquina em /docs/changelog.json, para você observar mudança sem raspar esta página.
2026-08-28
3 mudançasAdição compatívelAPI 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ívelAPI 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ívelAPI 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-21
8 mudançasAdição compatívelAPI REST e webhook
Módulo pep_sancoes: 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ívelAPI 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ívelAPI 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çãoAPI 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ívelWidget
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ívelPainel
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ívelSite 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çãoAPI 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.
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.