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.
EL 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 LAS SOLUCIONES ESTANDAR NO ALCANZAN
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 NORMADATA AYUDA
Como Normadata te ayuda
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.
MIRALO EN ACCION
Miralo en accion
# 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"LIMITACIONES
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.
PREGUNTAS FRECUENTES
Preguntas frecuentes
¿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).
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.