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.
O 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 AS SOLUCOES PADRAO NAO SAO SUFICIENTES
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 O NORMADATA AJUDA
Como o Normadata ajuda
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.
VEJA EM ACAO
Veja em acao
# 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 APILIMITACOES
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.
PERGUNTAS FREQUENTES
Perguntas frequentes
¿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.
Integre o Normadata no seu stack
Acesso antecipado. Entre na lista e daremos acesso à API.