Uma das preocupações mais comuns ao integrar APIs de consulta de CPF é o controle do volume de requisições. Os 50 créditos do Grátis, ao se esgotarem, pausam o serviço: HTTP 403, "Limite de créditos excedido". Se o plano for pago e prever excedente, o crédito extra é faturado depois, como na página de preços. O teto de chamadas por minuto devolve HTTP 429 e pede espera pelo Retry-After. O foco real, portanto, é gestão de custo: implementar cache, filas e monitoramento proativo para manter o consumo dentro do plano contratado e evitar surpresas na fatura.
Como Funciona o Modelo de Consumo
O limite de créditos e o limite por minuto são controles diferentes. No plano Grátis, acabar os 50 créditos pausa as consultas: a API responde HTTP 403 ("Limite de créditos excedido") e não cobra consulta extra. Nos planos pagos, a API continua e o excedente entra na fatura seguinte, conforme a página de preços. Passar de 30 requisições por minuto (5 por minuto na Consulta em Tempo Real) é outro caso: HTTP 429 com Retry-After, em qualquer plano.
| Plano CPFHub.io | Limite Mensal | Ao passar dos créditos |
|---|---|---|
| Free | 50 créditos/mês | Pausa. HTTP 403, sem cobrança por extra |
| Pro | 1.000 créditos/mês | Continua. O excedente vai para a fatura, no valor da página de preços |
| Corporativo | Sob consulta | Negociado |
No Grátis a aplicação para quando os créditos acabam. Nos planos pagos, um pico não planejado pode aparecer na fatura seguinte. As estratégias abaixo ajudam a manter o consumo sob controle.
Implementando Backoff Exponencial
O backoff exponencial é útil para tratar erros transitórios de rede e timeouts. A ideia é aumentar progressivamente o tempo de espera entre tentativas:
import requests
import time
import random
def consultar_cpf_com_retry(cpf, max_tentativas=5):
headers = {
"x-api-key": "SUA_CHAVE_DE_API",
"Accept": "application/json"
}
for tentativa in range(max_tentativas):
response = requests.get(
f"https://api.cpfhub.io/cpf/{cpf}",
headers=headers,
timeout=15 # considere a latência média de ~150 ms
)
if response.status_code == 200:
return response.json()
if response.status_code in (500, 503, 504):
# Backoff exponencial com jitter para erros de servidor
espera_base = 2 ** tentativa
jitter = random.uniform(0, 1)
tempo_espera = espera_base + jitter
print(f"Erro temporário. Tentativa {tentativa + 1}. "
f"Aguardando {tempo_espera:.1f}s...")
time.sleep(tempo_espera)
else:
print(f"Erro inesperado: {response.status_code}")
return None
print("Número máximo de tentativas atingido.")
return None
Por que adicionar jitter? Se múltiplas instâncias da sua aplicação falham simultaneamente, sem jitter todas tentariam novamente no mesmo instante, causando um "thundering herd". O jitter distribui as tentativas ao longo do tempo.
Utilizando Filas de Processamento
Para cenários com alto volume de consultas, uma fila de processamento é a solução mais robusta — ela regula o ritmo de requisições e evita picos que disparam cobranças extras:
const { Queue, Worker } = require('bullmq');
const axios = require('axios');
// Cria a fila de consultas de CPF
const filaCPF = new Queue('consulta-cpf', {
defaultJobOptions: {
attempts: 3,
backoff: {
type: 'exponential',
delay: 2000
}
}
});
// Worker que processa as consultas em ritmo controlado
const worker = new Worker('consulta-cpf', async (job) => {
const { cpf } = job.data;
const response = await axios.get(
`https://api.cpfhub.io/cpf/${cpf}`,
{
headers: {
'x-api-key': 'SUA_CHAVE_DE_API',
'Accept': 'application/json'
},
timeout: 15000 // 15s para acomodar latência de ~150 ms
}
);
return response.data;
}, {
limiter: {
max: 5, // Máximo de 5 consultas
duration: 60000 // Por minuto
}
});
// Adiciona CPFs à fila
async function agendarConsulta(cpf) {
await filaCPF.add('consultar', { cpf });
}
Cache Inteligente para Reduzir Requisições
Muitas aplicações consultam o mesmo CPF múltiplas vezes em um curto período. Um cache local pode reduzir dramaticamente o número de requisições — e, por consequência, o custo mensal:
- Cache em memória — ideal para aplicações de instância única
- Cache distribuído (Redis) — para aplicações com múltiplas instâncias
- TTL (Time to Live) — defina um tempo de expiração adequado (ex: 1 hora)
- Cache por CPF — armazene a resposta indexada pelo número do CPF
| Estratégia de Cache | Redução de Requisições | Complexidade |
|---|---|---|
| Sem cache | 0% | Nenhuma |
| Cache em memória (5 min TTL) | 30-50% | Baixa |
| Cache Redis (1 hora TTL) | 50-70% | Média |
| Cache Redis (24 horas TTL) | 70-90% | Média |
Atenção: ao usar cache com dados de CPF, garanta que o armazenamento seja criptografado e que o TTL esteja alinhado com a sua política de retenção de dados conforme a LGPD. A ANPD orienta que dados de identificação devem ser tratados com o princípio da necessidade e da minimização.
Monitorando o Consumo
Monitore proativamente o uso da API para evitar surpresas na fatura:
- Dashboard de consumo — visualize quantas consultas foram realizadas no período
- Alertas de threshold — configure alertas quando atingir 70% e 90% do limite
- Métricas por funcionalidade — identifique qual parte do sistema consome mais consultas
- Previsão de consumo — estime quando precisará fazer upgrade de plano
Quando Fazer Upgrade de Plano
Se o custo com consultas extras está crescendo, é hora de avaliar um upgrade:
- Custo extra recorrente — o valor mensal em consultas adicionais supera a diferença entre planos
- Fila de consultas crescendo — a demanda supera a capacidade planejada
- Clientes reclamando de lentidão — picos de consumo estão impactando a experiência
- Novo canal de aquisição — mais clientes significa mais consultas necessárias
Perguntas frequentes
A API CPFHub.io bloqueia minha aplicação quando o limite é atingido?
No Grátis as consultas param no fim dos 50 créditos: a resposta é HTTP 403, "Limite de créditos excedido". Nos planos pagos o excedente, quando existe, sai na fatura seguinte (veja a página de preços). Passar do limite por minuto é outro caso, HTTP 429 com Retry-After. Mas exige monitoramento de consumo para evitar custos inesperados.
Qual é a latência média da API de CPF?
A latência média da API CPFHub.io é de ~150 ms. Configure timeouts de pelo menos 10-15 segundos nas chamadas para acomodar variações de rede e evitar falhas prematuras. O backoff exponencial é recomendado para tratar erros transitórios.
Como garantir conformidade com a LGPD ao usar cache de CPF?
Ao armazenar respostas da API em cache, garanta que o armazenamento seja criptografado em repouso, que o TTL esteja alinhado à finalidade do tratamento e que apenas colaboradores autorizados acessem os logs. A ANPD orienta que dados de identificação devem ser tratados com os princípios da necessidade e da minimização.
Quanto custa ultrapassar o limite do plano Free?
O custo da consulta é em créditos: 1 na Consulta Simples e 1,5 na Consulta em Tempo Real. Esgotar os 50 créditos do Grátis pausa as chamadas com HTTP 403, "Limite de créditos excedido". Nos planos pagos, o valor do crédito excedente está na página de preços; passar do limite por minuto gera HTTP 429 com Retry-After. O upgrade de plano pode ser gerenciado em app.cpfhub.io/settings/billing.
Conclusão
Controlar o consumo de APIs de CPF é uma combinação de boas práticas técnicas: backoff exponencial para erros transitórios, filas de processamento para regular o ritmo de requisições, cache inteligente para eliminar consultas redundantes e monitoramento proativo para evitar surpresas na fatura. Os 50 créditos do Grátis, ao se esgotarem, pausam o serviço: HTTP 403, "Limite de créditos excedido". Se o plano for pago e prever excedente, o crédito extra é faturado depois, como na página de preços. O teto de chamadas por minuto devolve HTTP 429 e pede espera pelo Retry-After.
CPFHub.io
Pronto para integrar a API?
50 créditos gratuitos para testar agora. Sem cartão de crédito. Acesso imediato à documentação.




