Verificação de idade
O móduloage_assurance responde uma pergunta, e não a que a maioria espera: ele não diz a idade do titular, ele diz se o titular tem pelo menos 18 anos. A aferição sai da selfie, com prova de vida, e existe para o caso em que pedir documento de todo mundo é desproporcional. Ela depende da prova de vida: sem ela não há rosto ao vivo para aferir, e o módulo recusa antes de aferir qualquer coisa.
Disponível desde 11 de setembro de 2026. Ele aparece na tabela de preços e no GET /v1/capabilities com preço e status available, e pode ser ligado num flow. Até essa data a venda estava pausada, por licença do modelo que estima a idade: o peso anterior tinha origem restrita a pesquisa e foi retirado do produto. O que roda hoje tem cadeia de licença aberta, declarada na página de segurança.
O que chega é o veredito, e nada além dele. O bloco do módulo traz decision e minimum. A idade mínima é 18 anos, fixa: é a maioridade, e nenhum flow pede outra. A idade estimada não sai no payload, no webhook nem no painel, e não fica guardada: o sinal de idade atesta a condição sem revelar dado pessoal adicional. O sim só sai com margem de segurança acima dos 18, e o resto da faixa de dúvida vira inconclusivo em vez de chute. O seu código se apoia em decision.
YES é “tem a idade”, NO é “não tem”, INCONCLUSIVE é a faixa em que não afirmamos nem uma coisa nem outra, e NO_LIVENESS é o caso em que nem chegamos a aferir. O minimum pode vir null quando a selfie não teve qualidade para medida nenhuma.
O inconclusivo leva ao documento. Num flow de aferição de idade (a finalidade age_assurance, que todo flow só de age_assurance e liveness tem), o inconclusivo nunca é tratado como aprovação nem fica parado numa fila: a verificação termina sem aprovar, com o motivo age_document_required, e o seu servidor abre na hora uma nova sessão num flow com documento, que confirma os 18 anos pela data de nascimento. Num flow de identidade com idade, o inconclusivo continua indo à sua fila de revisão, e a sua política escolhe o passo seguinte. O roteiro completo, com o grau de risco e o que vale como verificação, está em ECA Digital: o que é seu e o que é nosso.
Quem discorda do resultado tem por onde contestar. Nas telas de recusa e de análise de um flow com age_assurance, o widget mostra ao titular, ao lado do botão de atendimento da sua empresa, que ele pode falar com o atendimento e pedir outra forma de comprovar a idade. Por isso, em produção, a criação de sessão de um flow com age_assurance exige o atendimento ligado na tela Customização do painel, e devolve age_contest_channel_required (422) quando ele está desligado; o sandbox fica livre. A reavaliação é pelo documento, e quem decide e responde ao titular é a sua empresa. Explique a aferição a quem vai passar por ela antes de abrir o widget e aponte a página Verificação de idade, escrita para o titular e a família.
No sandbox só existem YES e NO: o ambiente de testes não produz INCONCLUSIVE nem NO_LIVENESS, e chega a emitir o par outcome: "pending" com decision: "NO", que a produção nunca emite (lá NO é sempre failed). Trate esses dois vereditos como caminhos a implementar às cegas, e teste-os com o seu próprio duplo.