Análise de crédito
Cinco módulos consultam a situação de crédito do CPF lido do documento:credit_debts (dívidas e negativações), credit_scr (SCR do Banco Central), credit_boavista (Boa Vista SCPC), credit_protests (protestos Cenprot) e credit_cadin (CADIN). Exigem Verificação de Identidade, Face Match e Liveness, pela mesma razão dos cadastrais: o CPF consultado vem do documento, e o documento tem que pertencer a quem está vivo na frente da câmera.
O sexto, credit_pgfn (Dívida Ativa da União), é de empresa: ele consulta o CNPJ lido do documento societário e por isso exige apenas o cnpj_ocr no flow, sem biometria, porque empresa não tem rosto. A fonte dele não é fornecedor: é o dado aberto oficial que a PGFN publica e atualiza trimestralmente, ingerido na nossa base. Cada resposta carimba a competência publicada do arquivo que respondeu, para você saber a que mês ela se refere.
Venda pausada hoje: os cinco de CPF aparecem na tabela de preços e no GET /v1/capabilities com preço e status coming_soon, e não podem ser ligados num flow enquanto a fonte não for liberada na conta do fornecedor. O credit_pgfn saiu dessa fila em 11 de setembro de 2026 e viaja como available. O estado vem do catálogo vivo, e esta página acompanha.
Os cinco de CPF pedem finalidade, relação e consulente, como a Lei 12.414/2011 manda para dado de crédito. A finalidade é do flow: ao montá-lo no painel você declara credit_purpose, credit_risk_analysis ou credit_granting (art. 7º). A relação com o titular vai em cada sessão, no campo credit_relationship do POST /v1/verification-sessions: existing ou prospective (art. 15). O consulente é a sua empresa, e por isso a conta precisa ter o CNPJ cadastrado e verificado. A consulta só sai com a identidade aprovada, e cada uma fica registrada com a finalidade, a relação e o consulente. O credit_pgfn não passa por esse portão.
verification.completed posterior, quando a consulta conclui. Enquanto processa, o módulo aparece como pending sem a chave data; concluído, o data traz o dossiê do pacote. Se a fonte não concluir na janela, o módulo termina como indisponível e não é cobrado.
O credit_pgfn responde da nossa base, na mesma verificação, e não tem esses dois tempos. Em troca ele carrega a competência do arquivo do governo que respondeu, em reference_period e updated_at, mais a coverage por fonte. Quando a base está vencida ou incompleta, ele sai como pending com o motivo e não é cobrado: um nada consta só é emitido com a base inteira dentro do prazo. Achado positivo, ao contrário, é devolvido mesmo com cobertura incompleta, porque consta continua verdadeiro.
Sem dossiê, a chave data não vem null: ela não existe. Vale enquanto a fonte processa, quando ela não responde na janela e quando o documento não é encontrado. Um leitor que testa check.data === null não pega nenhum desses casos: teste a presença da chave, e ramifique por outcome.
Aqui o data é o dossiê da fonte, sem envelope nenhum: não há flagged, não há matched_by, não há bloco nosso em volta. Valem as mesmas duas regras da consulta cadastral: tiramos só pacoteUsado, saldo e consultaID, e o conjunto de chaves é o do pacote, não uma lista fechada nossa. Todo dossiê traz o bloco comum status, estado, cpf e nome, e os dois primeiros enganam: status é o indicador de sucesso da chamada (nunca a situação do titular) e estado é o estágio do processamento ("concluido"; a primeira chamada da fonte real pode responder "processando", que tratamos como indisponibilidade temporária). Os valores em dinheiro vêm em reais com decimais, e não em centavos como os saldos do topo do webhook.
As duas regras do parágrafo acima valem para os cinco de CPF, que repassam o dossiê do fornecedor. O credit_pgfn é a exceção nas duas: o payload dele é nosso, então não existe o bloco comum status, estado, cpf e nome, e o dinheiro sai em centavos inteiros, em total_amount_cents.