CASO DE USO
Marketplace multi-país: una API en vez de cinco librerías
Operás en 5+ países LATAM. Cada uno tiene su tax ID, su algoritmo de DV, su formato bancario. Hoy tenés una librería por país × una por lenguaje de tu stack — Node + Python + Go × Brasil + Argentina + México + Colombia + Chile. Eso es un infierno de mantenimiento. Normadata lo reemplaza con una API REST.
EL PROBLEMA
Mantener N librerías por país × M lenguajes no escala
Cada librería tiene su propia cadencia de releases, sus propios bugs, su propia interpretación del DV. Cuando un país cambia el formato (raro pero pasa) hay que actualizar N × M dependencies.
Drift entre librerías de distintos lenguajes
validator-rut-cl en Node valida "K" pero validator-rut-cl en Python rechaza "K" en minúscula. El front acepta el RUT, el backend lo rechaza, el seller llama soporte.
5+ librerías por país en tu monorepo
cpf-cnpj-validator + cuit-validator + ruc-pe-validator + rut-cl-validator + nit-co-validator + iban-validator. Cada una mantenida por una persona distinta. Cuando uno se abandona (suele pasar), tu monorepo queda con un fork interno que nadie mantiene.
Onboarding multi-país requiere routing por jurisdicción
El seller elige país → tu code llama a la librería correspondiente. Un switch/case por país. Por lenguaje. Por servicio. Por team que toca onboarding.
POR QUE LAS SOLUCIONES ESTANDAR NO ALCANZAN
Por qué OSS multi-país no escala
Librerías OSS individuales
Gratis y rápido para un país, pero el infierno arranca con el segundo. Cero envelope unificado entre librerías — cada una tiene su propio shape de respuesta.
Wrapper interno
Tu team escribe un wrapper sobre las 5 librerías. Ahora mantenés 5 librerías + 1 wrapper. Y el wrapper queda como deuda técnica que nadie quiere tocar.
Validación server-side custom
Escribís los algoritmos de DV vos mismo. Funciona hasta que cambia el formato o se agrega un país. Y tu time-to-add-country es 2 semanas en lugar de 1 día.
COMO NORMADATA AYUDA
Como Normadata te ayuda
POST /v1/verify con el payload del signup. Smart parse detecta el país y el tipo de identifier desde el shape. Pasás country_hint si lo tenés.
Para chequeo determinístico por país: POST /v1/verify/tax-id con country + type específicos. Mismo envelope de respuesta para los 10 países LATAM.
Cuando agregás un país nuevo, no agregás librería — solo agregás country al request body. Time-to-launch en un país nuevo se reduce de semanas a horas.
MIRALO EN ACCION
Miralo en accion
# Smart Parse — let Normadata auto-detect ID type
$ curl -X POST api.normadata.io/v1/verify \
-H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
-d '{"country":"MX","value":"GOMJ881217U2"}'
{
"valid": false,
"identifier": {
"type": "RFC",
"category": "tax_id"
},
"errors": ["invalid_length"]
}
# Multi-country signup: same endpoint for AR, BR, MX, CL, CO, PE...
# Replace 5+ country-specific npm libs with one consistent APILIMITACIONES
Lo que Normadata no hace en marketplace onboarding
—No auto-routea según jurisdicción legal. Si el seller tiene CUIT pero está operando en Brasil, ese es problema de tu rule engine de compliance — Normadata solo dice que el CUIT es estructuralmente válido.
—No detecta sellers fraudulentos. Format-only — el fraude usa identifiers válidos.
PREGUNTAS FRECUENTES
Preguntas frecuentes
¿Funciona si mi backend está en Go y el front en TypeScript?
Sí. La API es REST + JSON — cualquier lenguaje que pueda hacer fetch sirve. /docs/examples tiene cURL, TypeScript, Python y Go.
¿Cuánto cuesta vs mantener 5 librerías?
Depende del volumen y del costo interno de mantenimiento. La métrica más honesta: tiempo de tu team. Si tu eng team toca onboarding 1 día/mes por país que toca librería, esa hora vale mucho más que el call a la API.
Integra Normadata en tu stack
El acceso se otorga manualmente. Unite a la lista de espera y te damos acceso a la API.