Introdução
O tempo de resposta de uma API de CPF impacta diretamente a experiência do usuário e a taxa de conversão do seu onboarding. Cada 100ms de latência adicional pode significar perda de clientes. Mas como medir de forma justa e comparar provedores?
Métricas de latência que importam
A média de tempo de resposta é a métrica mais citada, mas é também a mais enganosa. Os percentis contam a história real da performance.
| Métrica | O que mede | Por que importa |
|---|---|---|
| p50 (mediana) | Tempo de 50% das requisições | Experiência típica do usuário |
| p95 | Tempo de 95% das requisições | Experiência da maioria absoluta |
| p99 | Tempo de 99% das requisições | Pior caso frequente |
| p99.9 | Tempo de 99,9% das requisições | Outliers que afetam SLA |
| Média | Soma / total | Distorcida por outliers, evitar usar |
| Desvio padrão | Variabilidade | Consistência do serviço |
- p95 é a métrica-chave -- se o p95 é 500ms, significa que 95% dos seus usuários terão resposta em menos de meio segundo
- Média mente -- se 99 requisições levam 100ms e 1 leva 10s, a média é 199ms, mas o p99 revela os 10 segundos
- Consistência importa -- um provedor com p50=200ms e p99=250ms é melhor que um com p50=150ms e p99=3000ms
Metodologia de benchmark
Para um benchmark válido, é preciso controlar variáveis e seguir uma metodologia rigorosa. Testes amadores geram conclusões erradas.
import time
import statistics
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
class ApiBenchmark:
def __init__(self, url, headers, total_requests=1000, concurrency=10):
self.url = url
self.headers = headers
self.total_requests = total_requests
self.concurrency = concurrency
self.results = []
def _single_request(self, cpf):
start = time.perf_counter()
try:
resp = requests.get(
self.url.format(cpf=cpf),
headers=self.headers,
timeout=15,
)
elapsed = (time.perf_counter() - start) * 1000
return {
"latency_ms": round(elapsed, 2),
"status": resp.status_code,
"success": resp.status_code == 200,
}
except Exception as e:
elapsed = (time.perf_counter() - start) * 1000
return {
"latency_ms": round(elapsed, 2),
"status": 0,
"success": False,
"error": str(e),
}
def run(self, cpfs: list):
with ThreadPoolExecutor(max_workers=self.concurrency) as executor:
futures = [
executor.submit(self._single_request, cpfs[i % len(cpfs)])
for i in range(self.total_requests)
]
for future in as_completed(futures):
self.results.append(future.result())
return self._analyze()
def _analyze(self):
latencies = [r["latency_ms"] for r in self.results if r["success"]]
errors = [r for r in self.results if not r["success"]]
latencies.sort()
return {
"total": len(self.results),
"success": len(latencies),
"errors": len(errors),
"error_rate": f"{len(errors)/len(self.results)*100:.2f}%",
"p50": latencies[len(latencies) // 2],
"p95": latencies[int(len(latencies) * 0.95)],
"p99": latencies[int(len(latencies) * 0.99)],
"mean": round(statistics.mean(latencies), 2),
"stdev": round(statistics.stdev(latencies), 2),
"min": min(latencies),
"max": max(latencies),
}
# Executar benchmark
bench = ApiBenchmark(
url="https://api.cpfhub.io/cpf/{cpf}",
headers={"x-api-key": "sua-chave-aqui"},
total_requests=1000,
concurrency=10,
)
resultado = bench.run(["12345678909", "98765432100"])
- Warmup -- descarte as primeiras 50-100 requisições para eliminar efeitos de cold start e DNS
- Volume mínimo -- execute pelo menos 1.000 requisições para ter significância estatística
- Concorrência realista -- simule o número de requisições simultâneas que sua aplicação realmente faz
- Horários variados -- teste em diferentes horários para capturar variações de carga do provedor
Fatores que afetam a latência
A latência medida não depende apenas do provedor. Vários fatores externos podem distorcer os resultados do benchmark.
| Fator | Impacto | Como controlar |
|---|---|---|
| Localização do servidor de teste | 10-100ms | Testar da mesma região dos seus servidores |
| DNS resolution | 5-50ms | Usar DNS cache ou IPs diretos |
| TLS handshake | 20-80ms | Manter conexões persistentes (keep-alive) |
| Carga no provedor | Variável | Testar em horários variados |
| Rede do provedor de cloud | 5-20ms | Testar de múltiplos provedores |
| Tamanho da resposta | 1-10ms | Comparar respostas equivalentes |
# Breakdown detalhado de latência com cURL
curl -w "\n--- Breakdown ---\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nPrimeiro byte: %{time_starttransfer}s\nTotal: %{time_total}s\nTamanho: %{size_download} bytes\n" \
-o /dev/null -s \
-H "x-api-key: sua-chave-aqui" \
"https://api.cpfhub.io/cpf/12345678909"
- DNS -- tempo para resolver o domínio; pode ser eliminado com cache DNS local
- TCP + TLS -- handshakes iniciais; reutilize conexões com HTTP keep-alive para evitar
- TTFB (Time to First Byte) -- o tempo até receber o primeiro byte da resposta, a métrica mais importante
Interpretando resultados
Com os dados em mãos, é preciso interpretar corretamente para tomar decisões fundamentadas.
| Classificação | p50 | p95 | p99 | Adequado para |
|---|---|---|---|---|
| Excelente | < 100ms | < 200ms | < 500ms | Pagamentos, tempo real |
| Bom | < 200ms | < 500ms | < 1000ms | Onboarding, cadastro |
| Aceitável | < 500ms | < 1000ms | < 2000ms | Backoffice, batch |
| Ruim | < 1000ms | < 3000ms | < 5000ms | Apenas processos offline |
| Inaceitável | > 1000ms | > 3000ms | > 5000ms | Não recomendado |
- Compare percentis, não médias -- dois provedores podem ter a mesma média, mas performances muito diferentes no p99
- Teste com sua carga real -- um provedor pode ser rápido com 10 req/s e lento com 100 req/s
- Reavalie periodicamente -- a performance de APIs muda com o tempo; faça benchmarks trimestrais
Perguntas frequentes
O que é necessário para implementar validação de CPF neste contexto?
A validação de CPF exige uma chamada à API com o número do documento e a chave de autenticação. A CPFHub.io retorna o status do CPF, nome do titular e data de nascimento em menos de 200ms, permitindo a verificação em tempo real durante o cadastro ou transação.
A API CPFHub.io funciona para todos os volumes de consulta?
Sim. O plano gratuito oferece 50 consultas por mês sem cartão de crédito — ideal para testes e projetos pequenos. Para volumes maiores, o plano Pro inclui 1.000 consultas mensais por R$149. Se o limite for ultrapassado, a API não bloqueia: cobra R$0,15 por consulta adicional.
Como garantir conformidade com a LGPD ao usar uma API de CPF?
Use o CPF apenas para a finalidade declarada ao titular, armazene apenas o necessário (não guarde o CPF cru se um token bastar), implemente controle de acesso aos logs de consulta e documente a base legal para o tratamento. A ANPD orienta que dados de identificação devem ser tratados com o princípio da necessidade.
Quanto tempo leva para integrar a API CPFHub.io?
A integração básica leva menos de 30 minutos: crie uma conta em cpfhub.io, gere a API key no painel e faça uma chamada GET para https://api.cpfhub.io/cpf/{CPF} com o header x-api-key. A documentação inclui exemplos em Python, Node.js, PHP, Java e outras linguagens.
Conclusão
Um benchmark bem conduzido é a base para escolher o provedor de API de CPF certo para sua operação. Foque nos percentis p95 e p99 em vez da média, controle as variáveis externas e teste com volume e concorrência realistas. Lembre-se de que a latência da API é apenas uma parte do tempo total da requisição: DNS, TLS e rede também contam. Acesse cpfhub.io para criar sua conta e rodar seu primeiro benchmark gratuitamente — o plano gratuito oferece 50 consultas mensais sem cartão de crédito.
CPFHub.io
Pronto para integrar a API?
50 consultas gratuitas para testar agora. Sem cartão de crédito. Acesso imediato à documentação.
Sobre a redação
Redação CPFHub.io
Time editorial especializado em APIs de CPF, identidade digital e compliance no mercado brasileiro. Produzimos guias técnicos, análises regulatórias e tutoriais sobre LGPD e KYC para desenvolvedores e líderes de produto.



