CASO DE USO
Reduce abandono de onboarding causado por validation errors
Los validators genéricos rechazan inputs LATAM válidos. El usuario tipea su CPF con puntos, el form lo rechaza, el usuario lo tipea sin puntos, el form lo rechaza igual. El usuario cierra la pestaña. Normadata acepta formatos variados, devuelve normalized + warnings accionables para mostrar inline UI.
O PROBLEMA
Validation rígida rompe el funnel de onboarding
El form tiene una opinión sobre el formato. El usuario tiene otra. Cuando no matchean, el usuario pierde. La conversión baja sin que el equipo de product sepa por qué.
El usuario tipea con puntos, el form quiere sin puntos
CPF copy-paste desde la cédula impresa viene con puntos. Tu regex espera \d{11}. Rechazo. Usuario re-tipea, este vez con los puntos sacados a mano. Encima del teclado mobile.
Field-level error sin guidance específica
"Formato inválido". OK pero ¿qué corrijo? El usuario no sabe si es length, charset, DV o algo más. Sin warnings específicos, la frustración acumula y el funnel se cae.
Mobile keyboard inserta caracteres invisibles
Espacios trailing, no-breaking spaces, zero-width chars copiados desde la app del banco. El regex rechaza. El usuario ve el mismo string que el form, no entiende por qué falla.
POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES
Por qué los validators genéricos pierden el funnel
Regex estricta
Una sola interpretación del formato. Si el usuario tipea diferente (incluso si es válido), pierde.
Mask inputs
Mejora UX pero rompe en copy-paste y en autocompletado mobile. Y no atrapa DV.
Sin validación del lado del cliente
Worst — el usuario completa el form, lo manda, espera, recibe error genérico del backend. Bounce rate máximo.
COMO O NORMADATA AJUDA
Como o Normadata ajuda
POST /v1/verify/tax-id en blur o submit del field. Acepta puntos, espacios, guiones, mask chars — Normadata normaliza. El usuario tipea como quiere.
El response.warnings tiene field path + reason code accionable. Mapeá los codes a mensajes UI específicos: "check_digit_failed" → "El CPF tiene un dígito mal — revisalo".
Mostrá el normalized en el field después de validar OK. El usuario ve su CPF con formato consistente — feedback positivo + builds trust en el form.
VEJA EM ACAO
Veja em acao
# User typed CPF with spaces — generic regex would reject
$ curl -X POST api.normadata.io/v1/verify/tax-id \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"BR","type":"cpf","value":"111 444 777 35"}'
{
"valid": true,
"normalized": "11144477735",
"formatted": "111.444.777-35"
}
# Accept dotted, spaced, masked, lowercase — return canonical form
# Only reject on checksum fail — not on cosmetic format quirks
# When valid=false, use 'errors' array for actionable inline UI:
# invalid_check_digit → "Verificá el número, parece tener un dígito mal"
# invalid_length → "Faltan dígitos"LIMITACOES
Lo que Normadata no hace en form UX
—No diseña el form ni el copy de errors. Te devuelve datos estructurados; vos hacés el UI.
—No reemplaza tu existing client-side validation — la complementa. Hace sentido tener regex de shape básica como first gate y Normadata como check exhaustivo.
PERGUNTAS FREQUENTES
Perguntas frequentes
¿En blur o en submit?
Depende de tu UX. Blur con debounce de 300ms es el balance común — feedback inmediato sin spam de calls. Submit-only es safe pero el usuario descubre el error tarde.
¿Funciona offline?
Es una REST API — necesita network. Para offline tenés que cachear validations comunes client-side o usar tools client-side (lib/validators/* en este repo open-source la lógica para CUIT/CPF/CNPJ/RFC/etc., pero no es oficial).
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.