normadata
PT-BR
Pedir acesso →
CASO DE USO

Onboarding com identifiers de varios paises LATAM em um unico flow

Seu produto opera em 10 paises LATAM. Cada um tem seu tax ID, seu algoritmo de check-digit, seu formato de mascara, suas regras de prefixo. Manter 10 bibliotecas por pais — cada uma com sua API, sua cadencia de updates, seu drift de manutencao — e overhead operacional. Uma API unica para validar tax IDs de todos os paises consolida a stack.

Entrar na lista de esperaLer documentacao
O PROBLEMA

Multiplos paises = multiplas implementacoes de validacao

Um produto LATAM que cresce para 5-10 paises termina com 5-10 validadores por pais. Cada um com sua API, sua shape de resposta, sua manutencao. Drift entre eles e inevitavel.

Cada pais tem seu algoritmo
CPF (BR) usa duplo digito verificador sequencial. CUIT (AR) usa modulo-11 com pesos fixos. RFC (MX) tem homoclave complexa. RUT (CL) usa modulo-11 com tabela. NIT (CO), RUC (PE), RIF (VE), CI (EC) — cada um com sua formula.
Drift entre bibliotecas por pais
A biblioteca de CPF atualizou ano passado. A de CUIT nao mexe ha tres anos. Cada uma tem um mantenedor diferente, uma cadencia diferente de releases, um nivel diferente de testes. A consistencia entre paises e fragil.
Response shape diferente por biblioteca
Uma biblioteca retorna boolean. Outra retorna enum. Outra retorna objeto. O time de produto escreve wrappers para uniformizar — e mantem tres niveis de adapter.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES

Por que as solucoes existentes nao consolidam bem

Uma biblioteca npm/PyPI por pais
Funciona mas soma N dependencias. Cada update de uma biblioteca e um release do seu produto. Versoes ficam pinned e desatualizadas.
Validar tudo no backend com codigo custom
Implementar 10 algoritmos corretamente, com testes, casos de borda, performance e manutencao — e projeto de meses e trabalho recorrente.
Confiar na validacao do KYC vendor
Funciona mas o vendor cobra por tentativa. Voce gasta dinheiro em validacao estrutural que poderia ser feita mais barato upstream.
COMO O NORMADATA AJUDA

Como o Normadata ajuda

Chame /v1/verify (smart parse) ou verify/tax-id com country como hint. O response shape e o mesmo para todos os paises: valid, normalized, identifier.type, errors[]. Seu codigo de produto e um so.
Smart parse autodetecta o tipo quando country nao e passado — util para signups onde o usuario comeca a digitar antes de selecionar pais. Para precisao, recomendamos passar country quando ja se conhece.
Mesmo endpoint, mesmo schema, multiplos paises: BR (CPF/CNPJ), AR (CUIT/CUIL/DNI), CL (RUT), CO (NIT/RUT/CC), PE (RUC/DNI), UY (RUT/CI), EC (CI), VE (CI/RIF). MX (RFC/CURP) em validators client-side; endpoint API em desenvolvimento.
VEJA EM ACAO

Veja em acao

# Smart Parse — no country hint, let the API try to detect
$ curl -X POST api.normadata.io/v1/verify \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"value":"20-31456789-0"}'

{
  "valid": true,
  "normalized": "20314567890",
  "identifier": {
    "type": "CUIT",
    "country_detected": "AR"
  }
}

# Best practice: pass 'country' when you know it — heuristics are not infallible
$ curl -X POST api.normadata.io/v1/verify/tax-id \
  -H "X-API-Key: nd_..." \
  -d '{"country":"BR","type":"cpf","value":"111.444.777-35"}'

# Same response shape across AR / BR / MX / CL / CO / PE / UY / EC / VE
LIMITACOES

O que o Normadata nao faz aqui

—O Normadata nao auto-roteia por jurisdicao legal. Se um usuario argentino se cadastra no seu produto BR, validamos o tax ID — mas a decisao sobre que regras legais aplicam (qual entidade legal, que pais factura) e sua.
—O Normadata nao e um rule engine de compliance. Nao conhece regras de KYC, AML ou tax por pais — isso fica com suas integracoes especializadas (KYC vendor, tax engine, etc).
Ver limitacoes completas
PERGUNTAS FREQUENTES

Perguntas frequentes

Detecta o pais sem passar country no request?
Smart parse tenta detectar por heuristica do valor (comprimento, prefixo, caracteres). Funciona razoavelmente bem mas nao e infalivel — um CPF de 11 digitos e um DNI de 11 digitos compartilham comprimento. Recomendamos passar country quando se conhece, para maior precisao.
Suporta os 10 principais paises LATAM?
Sim — BR, AR, CL, CO, PE, UY, EC, VE tem endpoint API hoje. MX (RFC/CURP) tem validators client-side disponiveis; o endpoint API esta em desenvolvimento. Todos compartilham o mesmo response shape.
Ver validadores →
See endpoint in docs →

Integre o Normadata no seu stack

Acesso antecipado. Entre na lista e daremos acesso à API.

Entrar na lista de esperaLer documentacao