CASO DE USO

Onboarding con identifiers de varios paises LATAM en un solo flow

Tu producto opera en 10 paises LATAM. Cada uno tiene su tax ID, su algoritmo de check-digit, su formato de mascara, sus reglas de prefijo. Mantener 10 librerias por pais — cada una con su API, su cadencia de updates, su drift de mantenimiento — es overhead operativo. Una API unica para validar tax IDs de todos los paises consolida la stack.

Unirme a la lista de espera Leer documentacion

EL PROBLEMA

Multiples paises = multiples implementaciones de validacion

Un producto LATAM que crece a 5-10 paises termina con 5-10 validadores por pais. Cada uno con su API, su shape de respuesta, su mantenimiento. Drift entre ellos es inevitable.

Cada pais tiene su algoritmo

CUIT (AR) usa modulo-11 con pesos fijos. CPF (BR) usa doble digito verificador secuencial. RFC (MX) tiene homoclave compleja. RUT (CL) usa modulo-11 con tabla. NIT (CO), RUC (PE), RIF (VE), CI (EC) — cada uno con su propia formula.

Drift entre librerias por pais

La libreria de CPF se actualizo el ano pasado. La de CUIT no se toca hace tres anos. Cada una tiene un mantenedor distinto, una cadencia distinta de releases, un nivel distinto de testing. La consistencia entre paises es fragil.

El response shape es distinto por libreria

Una libreria devuelve boolean. Otra devuelve enum. Otra devuelve objeto. El equipo de producto escribe wrappers para uniformar — y mantiene tres niveles de adapter.

POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN

Por que las soluciones existentes no consolidan bien

Una libreria npm/PyPI por pais

Funciona pero suma N dependencias. Cada update de una libreria es un release de tu producto. Las versiones quedan pinned y desactualizadas.

Validar todo en el backend con codigo custom

Implementar 10 algoritmos correctamente, con tests, casos borde, performance, mantenimiento — es proyecto de meses y trabajo recurrente.

Confiar en validacion del KYC vendor

Funciona pero el vendor cobra por intento. Gastas plata en validacion estructural que podrias hacer mas barato upstream.

COMO NORMADATA AYUDA

Como Normadata te ayuda

Llama a /v1/verify (smart parse) o verify/tax-id con country como hint. El response shape es el mismo para todos los paises: valid, normalized, identifier.type, errors[]. Tu codigo de producto es uno solo.

Smart parse auto-detecta el tipo cuando el country no se pasa — util para signups donde el usuario empieza a tipear antes de seleccionar pais. Para precision, recomendamos pasar country cuando ya lo conoces.

Mismo endpoint, mismo schema, multiples paises: AR (CUIT/CUIL/DNI), BR (CPF/CNPJ), CL (RUT), CO (NIT/RUT/CC), PE (RUC/DNI), UY (RUT/CI), EC (CI), VE (CI/RIF). MX (RFC/CURP) en validators client-side; endpoint API en desarrollo.

MIRALO EN ACCION

Miralo en accion

# 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

LIMITACIONES

Que no hace Normadata aqui

—Normadata no auto-routea segun jurisdiccion legal. Si un usuario brasileno se registra en tu producto AR, Normadata valida el tax ID — pero la decision sobre que reglas legales aplican (cual entidad legal, que pais factura) la haces vos.

—Normadata no es un rule engine de compliance. No conoce las reglas de KYC, AML o tax por pais — eso lo manejan tus integraciones especializadas (KYC vendor, tax engine, etc).

Ver limitaciones completas

PREGUNTAS FRECUENTES

Preguntas frecuentes

Detecta el pais sin pasar country en el request?

Smart parse intenta detectarlo por heuristica del valor (longitud, prefijo, caracteres). Funciona razonablemente bien pero no es infalible — un CPF de 11 digitos y un DNI de 11 digitos comparten longitud. Recomendamos pasar country cuando lo conoces para mayor precision.

Soporta los 10 paises principales de LATAM?

Si — AR, BR, CL, CO, PE, UY, EC, VE tienen endpoint API hoy. MX (RFC/CURP) tiene validators client-side disponibles; el endpoint API esta en desarrollo. Todos comparten el mismo response shape.

Ver validadores →

Ver endpoint en docs →

Integra Normadata en tu stack

El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.

Unirme a la lista de espera Leer documentacion