CASO DE USO
Reduza o abandono de onboarding causado por validation errors
Os validators genéricos rejeitam inputs LATAM válidos. O usuário digita o CPF com pontos, o form rejeita; digita sem pontos, o form rejeita igual. O usuário fecha a aba. A Normadata aceita formatos variados e devolve normalized + warnings acionáveis para mostrar inline na UI.
O PROBLEMA
Validation rígida quebra o funnel de onboarding
O form tem uma opinião sobre o formato. O usuário tem outra. Quando não batem, o usuário perde. A conversão cai sem o time de product saber por quê.
O usuário digita com pontos, o form quer sem pontos
CPF copy-paste do documento impresso vem com pontos. Sua regex espera \d{11}. Rejeição. O usuário redigita, dessa vez com os pontos tirados na mão. Em cima do teclado mobile.
Field-level error sem guidance específico
"Formato inválido". OK mas o que eu corrijo? O usuário não sabe se é length, charset, DV ou outra coisa. Sem warnings específicos, a frustração acumula e o funnel cai.
Mobile keyboard insere caracteres invisíveis
Espaços trailing, no-breaking spaces, zero-width chars copiados do app do banco. A regex rejeita. O usuário vê a mesma string que o form, não entende por que falha.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por que os validators genéricos perdem o funnel
Regex estrita
Uma única interpretação do formato. Se o usuário digita diferente (mesmo que válido), perde.
Mask inputs
Melhora UX mas quebra em copy-paste e em autocomplete mobile. E não pega DV.
Sem validação client-side
Pior — o usuário completa o form, envia, espera, recebe erro genérico do backend. Bounce rate máximo.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/validate/tax-ids no blur ou submit do field. Aceita pontos, espaços, hífens, mask chars — a Normadata normaliza. O usuário digita como quer.
O response.warnings tem field path + reason code acionável. Mapeie os codes para mensagens UI específicas: "check_digit_failed" → "O CPF tem um dígito errado — revise".
Mostre o normalized no field depois de validar OK. O usuário vê o CPF com formato consistente — feedback positivo e builds trust no form.
VEJA EM ACAO
Veja em acao
# User typed CPF with spaces — a generic regex would reject it
$ curl -X POST api.normadata.io/v1/validate/tax-ids \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"items":[{"id":"f","country":"BR","type":"cpf","value":"111 444 777 35"}]}'
{
"results": [
{ "id": "f", "valid": true, "normalized": "11144477735", "formatted": "111.444.777-35" }
]
}
# Accept dotted, spaced, masked, lowercase — return the canonical form
# Only reject on checksum fail — not on cosmetic format quirks
# When valid=false, map the per-item 'error' to actionable inline UI:
# invalid_check_digit → "Verificá el número, parece tener un dígito mal"
# invalid_length → "Faltan dígitos"LIMITACOES
O que a Normadata não faz em form UX
—Não desenha o form nem o copy dos errors. Devolve dados estruturados; você faz a UI.
—Não substitui sua existing client-side validation — complementa. Faz sentido ter regex de shape básica como first gate e a Normadata como check exaustivo.
PERGUNTAS FREQUENTES
Perguntas frequentes
No blur ou no submit?
Depende da sua UX. Blur com debounce de 300ms é o balance comum — feedback imediato sem spam de calls. Submit-only é safe mas o usuário descobre o erro tarde.
Funciona offline?
É uma REST API — precisa de network. Para offline você tem que cachear validations comuns client-side ou usar tools client-side (lib/validators/* neste repo open-source a lógica para CUIT/CPF/CNPJ/RFC/etc., mas não é oficial).
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.