LGPD e consulta de CPF via API: finalidade, base legal e o que guardar

Transparência: sou fundador da CPFHub, uma API de consulta de CPF. Este artigo não é aconselhamento jurídico. É um guia prático para desenvolvedores; para o seu caso concreto, consulte um especialista.

Integrar uma API de consulta de CPF leva uma tarde. Integrar do jeito certo do ponto de vista da LGPD (Lei nº 13.709/2018) exige algumas decisões antes da primeira linha de código. Este guia reúne as perguntas que costumo ver em times de produto e engenharia e o que elas significam na prática.

Primeiro: quem é o controlador?

Quando sua aplicação consulta um CPF para decidir algo sobre um cliente, você é o controlador desses dados no contexto da sua aplicação: é você quem decide por que e como eles são tratados. O fornecedor da API atua no papel que o contrato e a política dele definirem. Isso importa porque as obrigações principais — ter base legal, informar o titular, atender pedidos de acesso e exclusão — recaem sobre quem decide a finalidade.

Finalidade antes de tudo

A LGPD exige finalidade legítima, específica e informada ao titular. Antes de integrar, escreva em uma frase por que você consulta o CPF. Exemplos que fazem sentido:

• confirmar que o nome informado no cadastro corresponde ao CPF, para prevenir fraude;
• verificar maioridade antes de liberar um serviço restrito;
• conferir a situação cadastral na Receita antes de conceder crédito ou emitir um documento fiscal.

Exemplos que não fazem sentido: "enriquecer a base para marketing", "consultar todo mundo que visitou o site", "descobrir quem é o dono de um CPF qualquer". Se a frase não convence você, não vai convencer a ANPD.

Bases legais mais comuns

O art. 7º da LGPD lista as hipóteses que autorizam o tratamento. Para consulta de CPF, as mais usadas costumam ser:

• Cumprimento de obrigação legal ou regulatória (art. 7º, II): empresas reguladas, como instituições financeiras e seguradoras, com obrigações de identificação de clientes e prevenção à lavagem de dinheiro.
• Execução de contrato (art. 7º, V): validar os dados da pessoa que está contratando com você.
• Legítimo interesse (art. 7º, IX): prevenção a fraude, segurança da plataforma e integridade do cadastro — de forma proporcional e transparente. Legítimo interesse pede uma avaliação documentada (o chamado teste de balanceamento): o seu interesse, a necessidade do dado e as expectativas do titular.

Consentimento é possível, mas costuma ser frágil para prevenção a fraude: o titular pode revogá-lo, e quem frauda não vai consentir.

Minimização: consulte e guarde só o necessário

O princípio da necessidade (art. 6º, III) é o que mais muda o código. Algumas regras práticas:

Escolha a consulta mínima. Se você só precisa confirmar nome e idade, uma consulta simples (nome, gênero, data de nascimento) basta. A consulta da situação cadastral na Receita só se justifica quando o status muda a decisão. Na CPFHub, por exemplo, a consulta simples custa 1 crédito e a em tempo real 1,5 — mas o argumento aqui não é custo, é coletar menos.

Guarde o resultado da checagem, não a resposta inteira. Em vez de persistir o JSON completo, grave algo como:

{ "cpf_verificado": true, "nome_confere": true, "verificado_em": "2026-10-12" }

Defina prazo de retenção. Mantenha os resultados só pelo tempo necessário para a finalidade (ou exigido por obrigação legal) e automatize a exclusão.

Não duplique dados em lugares esquecidos: logs de aplicação, ferramentas de observabilidade, execuções salvas de automações (n8n, Make, Zapier), planilhas exportadas e tickets de suporte.

Segurança: o básico que evita incidentes

• A chave da API fica no servidor. Nunca no front-end, no app mobile ou no repositório. Chamada direta do navegador expõe a chave a qualquer um.
• Não registre CPFs completos em logs. Mascare (123.***.***-09) ou use um hash quando precisar correlacionar eventos.
• Comprovantes são dados pessoais. Algumas APIs devolvem links de comprovante da consulta que abrem nome, CPF e situação para quem tiver o link. Guarde-os só no back-end e nunca os envie ao cliente sem necessidade.
• Controle de acesso interno. Nem todo mundo no time precisa consultar CPFs; restrinja quem pode disparar consultas manuais.

Transparência com o titular

Informe na sua política de privacidade que os dados cadastrais podem ser verificados junto a provedores de validação de identidade e prevenção a fraudes, qual a finalidade e por quanto tempo os resultados ficam guardados. Uma linha no formulário de cadastro ("Vamos conferir seu CPF para proteger sua conta") ajuda a alinhar expectativas.

Direitos do titular

O titular pode pedir acesso, correção e exclusão dos dados que você armazena. Se você seguiu a minimização, a resposta é simples: "guardamos que seu CPF foi verificado em tal data". Tenha um processo (mesmo que manual) para atender esses pedidos no prazo.

Checklist para avaliar um fornecedor

• De onde vêm os dados? (Base própria, fontes licenciadas, consulta à Receita em tempo real?)
• O fornecedor vende listas ou usa as consultas para marketing?
• Ele informa a um cliente quais CPFs outros clientes consultaram?
• Há documentação de LGPD, termos de uso e política de privacidade públicos?
• Quais dados ele não retorna? (Menos dados retornados = menos risco para você.)

Como referência, a página de Compliance & LGPD da CPFHub responde a essas perguntas para o nosso caso; peça o equivalente a qualquer fornecedor que avaliar.

Resumo

1. Escreva a finalidade em uma frase antes de integrar.
2. Escolha a base legal adequada e documente o legítimo interesse, se for o caso.
3. Use a consulta mínima e guarde o resultado da checagem, não a resposta.
4. Chave no servidor, CPF mascarado nos logs, comprovantes protegidos.
5. Seja transparente com o titular e tenha processo para atender pedidos.

Repetindo: isto é orientação geral, não aconselhamento jurídico. Para casos regulados ou de alto volume, envolva seu DPO ou um advogado especializado em proteção de dados.